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Abstract:  This  bibliography  contains  entries  for  nearly  200 
books,  articles  and  papers  representing  the  work  and  interests  of 
I FIP  Working  Group  2.3  on  Programming  Methodology  (WG2.3).  This 
edition  is  a  first,  and  very  preliminary,  version  of  what  we  hope 
will  become  a  useful  guide  to  an  important  core  of  the 
Programming  Methodology  literature.  We  intend  to  include  items 
that 

(a)  are  on  programming  methodology  and  were  written  by 
members  of  WG2. 3, 

(b)  were  presented  at  WG2.3  meetings,  or 

(c)  explicitly  acknowledge  WG2.3. 

Entries  in  this  edition  were  compiled  primarily  from  lists 
provided  by  WG2.3  members  and  from  the  results  of  an  extensive 
literature  search;  most  of  them  meet  criterion  (a) .  The 
annotations  provided  in  this  edition  come  from  Computing  Reviews. 


The  Computer  Systems  Research  Group  (CSRG)  is  an 
interdisciplinary  group  formed  to  conduct  research  and 
development  relevant  to  computer  systems  and  their  applications. 
It  is  jointly  administered  by  the  Department  of  Electrical 
Engineering  and  the  Department  of  Computer  Science  of  the 
University  of  Toronto,  and  is  supported  in  part  by  the  National 
Research  Council  of  Canada. 
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Preface 


This  bibliography  contains  entries  for  books,  articles  and 
papers  representing  the  work  and  interests  of  IFIP  Working  Group 
2.3  on  Programming  Methodology  (WG2.3).  This  edition  is  a  first, 
and  very  preliminary,  version  of  what  we  hope  will  become  a 
useful  guide  to  an  important  core  of  the  Programming  Methodology 
literature.  We  intend  to  include  items  that 

(a)  are  on  programming  methodology  and  were  written  by 
members  of  WG2.3, 

(b)  were  presented  at  WG2.3  meetings,  or 

(c)  explicitly  acknowledge  WG2.3. 

Entries  in  this  edition  were  compiled  primarily  from  lists 
provided  by  WG2.3  members  and  from  the  results  of  an  literature 
search  by  Greenspan;  most  of  them  meet  criterion  (a).  The 
annotations  in  this  edition  come  from  Computing  Reviews.  We 
request  that  WG2.3  members  and  other  readers  of  the  bibliography 
actively  contribute  to  future  editions.  In  particular, 
contributions  of  the  following  kinds  are  needed: 

-  further  annotations 

-  replacement  annotations 

-  further  entries 

-  deletions 

-  corrections 

-  suggestions 

Please  write  to: 

J.  J.  Horning 

Xerox  Research  Center 

3333  Coyote  Hill  Road 

Palo  Alto,  CA  94304 

DSA 

A  note  on  ordering  of  co-authors'  names:  Use  of  the 

conjunction  'with'  indicates  that  a  WG2.3  member's  name  was 
placed  first  in  the  list  of  co-authors,  although  the  order  on  the 
publication  was  different. 
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■■■  Balzer,  R.M.;  A  Language-Independent  Programmer’s  Interface; 
in  Proc.  AFIPS  1974  National  Computer  Conference,  Vol.43,  AFIPS 
Press,  Montvale,  N.J.,  pp. 365-370,  See  main  entry  CR  15,10  (Oct. 
1974) ,  Rev. 27,233. 

The  thesis  of  this  article  is  that  an  on-line  programming 
environment  is  more  or  less  independent  of  the  programming 
language  used.  That  is,  it  is  possible  to  construct  a 
programming  environment  (called  the  Programmer’s  Interface)  which 
can  be  used  with  many  different  programming  languages  provided 
that  the  translators  and  run-time  packages  have  certain 
properties. 

The  author  describes  a  prototype  developed  to  verify  his  thesis, 
and  provides  both  an  operational  paradigm  and  an  example  of  the 
prototype  Programmer's  Interface  working  with  an  "added 
language.  " 

The  article  is  clearly  written,  although  I  found  the  example 
difficult  to  follow.  Designers  of  on-line  programming  systems 
should  read  this  article,  then  use  it  as  a  touchstone.  Partisans 
of  single-language  programming  systems  (APL,  PL/I,...)  should 
read  this  article  as  a  means  of  obtaining  perspective.  The  rest 
of  us  should  simply  hope  that  the  message  is  received  and 
understood.  [CR28,257  E. R.  Lassettre] 


■■■  Balzer,  R.M.;  EXDAMS-EXtendable  Debugging  and  Monitoring 
System;  AFIPS  1969,  Vol.34  (1969)  pp. 567-80. 


■■■  Balzer,  R.M. ,  and  Farber,  D. J. ;  APAREL-a  Parse  Request 
Language;  CACM  12,11  (November  1969)  pp. 624-631. 


■■■  Balzer,  R.M.,  with  Shirley,  R.W.;  The  On-line  Firing  Squad 
Simulator;  in  Proc.  AFIPS  1968  Fall  Joint  Computer  Conference, 
part  I,  233-241.  See  main  entry  CR10,5  (May  1969),  Rev. 16, 635. 

The  authors  discuss  a  particular  example  of  graphic  man/machine 
interaction  as  an  aid  to  problem-solving;  that  of  finding  a 
minimum  time  solution  to  the  firing  squad  synchronization 
problem.  The  paper  is  particularly  interesting  for  its  1) 
presentation  of  this  problem  in  automata;  2)  demonstration  of  a 
working  interactive  graphics  system  for  problem-solving  (FS5) ; 
and  3)  recommendations  concerning  this  type  of  man/machine 
programming. 

The  problem  statement  and  a  discussion  of  its  relevance  are 
contained  in  the  paper.  A  somewhat  detailed  description  of  the 
Firing  Squad  Synchronization,  Simulation  and  Solution  System 
(FS5)  follows,  indicating  that,  although  solutions  are  obtainable 
by  hand,  they  should  be  obtained  much  more  readily  using  FS5 . 
However,  there  are  no  reports  included  on  the  system's 
performance  in  use  that  would  prove  this  true.  There  is  then  a 
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description  of  what  is  needed  in  hardware  and  programming  to 
produce  other  such  graphic  programs.  The  conclusion,  and  the 
real  point  of  the  paper,  is  that  these  programs  can  be  great 
aids  in  problem-solving  and  should  be  seriously  considered  by 
anyone  researching  a  problem  area.  [CR17,458  R.R.  Coulter, Jr. ] 


■■■  Balzer,  R.M.;  Search  for  a  solution:  a  case  study;  in  Proc 
International  Joint  Conference  on  Artificial  Intelligence,  1969, 
21-31.  See  main  entry  CR  Rev. 20, 283. 

This  paper  describes  a  series  of  attempts  at  the  solution  of  a 
conceptually  tough  problem,  the  Firing  Squad  Synchronization 
Problem.  These  attempts  demonstrate  an  increasing  reliance  on 
man-machine  symbiosis  and  decreasing  reliance  on  powerful 
heuristic  and  preplanning. 

These  attempts  consist  of  a  clerical  checking  program,  and  four 
attempts  utilizing  a  basic  backtracking  program  for  searching  the 
solution  space. 

From  the  Abstract 


■■■  Balzer,  R.M.;  PORTS-A  Method  for  Dynamic  Interprogram 
Communication  and  Job  Control;  Proc.  of  the  SJCC  38  (1971) 
pp. 485-489. 

PORTS  is  a  technique  for  dynamically  establishing  a  communication 
link  between  a  program  and  any  other  entity  such  as  another 
program,  a  data  set,  or  a  device.  The  author  proposes  that  PORTS 
be  established  as  a  single  software  interface  to  replace  the 
current  hodgepodge  of  access  methods.  The  concept  of  continually 
re-establishing  such  communication  links  in  today's  operating 
systems  raises  as  yet  unanswered  questions  about  performance. 
This  technique  may  work  best  in  interpretive  systems  such  as  APL. 

The  paper  is  good;  the  concept  is  excellent;  and  PORTS  should  be 
a  required  subject  for  study  by  all  operating  system  designers. 
[ CR22 , 799  W.J.  Doherty] 


■■■  Balzer,  R.M.;  On  the  Future  of  Computer  Program  Specification 
and  Organization;  Rand  Corp. ,  Santa  Monica,  Cal.,  no.  R-622-ARPA 
(August  1971)  pp.1-23. 


■  ■■  Balzer,  R.M.,  with  Greenfeld,  N.,  Kay,  M.,  Mann,  W.  ,  Ryder, 
W.,  Wilczynski,  D.,  and  Zobrist,  A.;  Domain-Independent  Automatic 
Programming;  IFIP  1974,  North-Holland  Publishing  Co.  (1974) . 

This  paper  describes  the  framework  of  quite  a  challenging 
undertaking.  Its  goal  is  concisely  stated  by  the  authors: 

...This  project  is  not  seen  as  an  incremental  advance  in  computer 
languages  or  the  art  of  programming,  but  rather  as  an  attempt  to 
make  the  power  of  the  computer  available  to  a  large  class  of 


5 


users  without  the  necessity  of  a  step  similar  to  the  one  now 
called  programming.  Ultimately,  a  client  should  be  able  to 
negotiate  directly  with  a  computer  system  in  much  the  same  terms 
as  he  now  negotiates  with  a  programmer. 

From  the  Text 

The  paper  discusses  in  some  detail  the  processing  modules  and 
data  bases  that  comprise  the  system  design.  An  example  of  the 
system's  planned  behavior  is  presented.  [CR27,815  L.  Presser  ] 


■■■  Brinch  Hansen,  P. ;  An  Outline  of  a  Course  on  Operating  System 
Principles;  in  Operating  systems  techniques  1972,  29-36.  See 
main  entry  CB14,9  (Sept.  1973),  Rev. 25, 650. 

The  author  commenced  work  on  a  text  for  a  course  on  operating 
system  principles  in  November  1970.  This  chapter  describes  the 
structure  of  the  course  and  how  far  it  has  progressed  (November 

1 971)  . 

He  believes  that  the  study  of  operating  systems  leads  to  the 
recognition  of  general  principles  which  should  be  taught  as  part 
of  a  core  of  computer  science.  Operating  systems  are  merely 
large  programs  based  on  fundamental  principles  of  computer 
science.  Through  their  study,  these  fundamentals  can  be 
identified . 

The  outline  explains  that  the  course  deals  with  the  problems 
faced  by  all  operating  systems.  These  are  the  principles  common 
to  all  operating  systems  which  must  be  grasped  before  the 
problems  of  adjusting  to  the  constraints  of  a  certain  environment 
can  be  tackled.  Therefore  the  concentration  is  on  process 
synchronization,  storage  management  and  resource  protection,  not 
on  input/output  and  filing  systems. 

Course  on  Operating  System  Principles. 

A  description  of  a  text  book  in  progress. 

Definitions;  Operating  System;  Sharing;  Schedule;  Protect; 
Accounting;  Measure  actual  performance. 

The  proper  aim  of  education  is  to  identify  the  fundamental 
principles  of  computer  science. 

The  author's  argument;  the  study  of  operating  systems  leads  to 
the  recognition  of  general  principles  which  should  be  taught  as 
part  of  a  core  of  computer  science.  [CR26,738  A.K.  Campbell] 


■■■  Brinch  Hansen,  P. ;  RC  4000  Software:  Multiprogramming  System; 
Regnecentralen,  Copenhagen,  Denmark  (April  1969). 


■  ■■  Brinch  Hansen,  P.  ;  The  Nucleus  of  a  Multiprogramming  System; 
C  ACM  13,4  (April  1970)  pp. 238-250. 


■  Brinch  Hansen,  P.;  Structured  Multiprogramming;  CACM  15,7 
(1972)  pp. 574-578. 
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This  paper  summarizes  a  multiprogramming  facility  for  a  high- 
level  language.  The  goal  is  production  of  understandable 
programs  and  provision  of  compile-time  detection  of  mutual 
interference,  particularly  conflicts  in  use  of  shared  data. 
Although  the  language  chosen  is  PASCAL,  any  block-structured 
language  would  do. 

Features  of  the  facility  are:  parallelism  using  concurrent 
statements;  "critical  Regions"  for  exclusive  access  to  shared 
variables;  and  two  general  waiting  mechanisms  for  process 
synchronization.  The  waiting  mechansims  use  arbitrary  Boolean 
expressions  for  wakeup  conditions  and  critical  regions  to  avoid 
the  "lost  wakeup"  problem,  and  they  allow  some  self-scheduling  by 
the  program. 

The  ideas  presented  are  worthy  of  consideration  by  anyone 
interested  in  multiprogramming.  Unfortunately  the  paper  is 
brief.  An  axiomatic  approach  is  introduced  for  defining 
noninterference  and  critical  sections,  but  is  not  extended  to  the 
waiting  mechanisms.  Deadlocks  are  not  mentioned.  Thus,  this 
paper  is  an  interesting  starting  point,  but  its  ideas  need 
considerable  development.  [CR24,238  J.H.  Howard, Jr. ] 


Brinch  Hansen,  P. ;  A  Comparison  of  Two  Synchronizing 
Concepts;  Acta  Informatica  1  (1972)  pp. 190-199. 

This  article  addresses  an  interesting  topic,  and  contains  a  lot 
of  food  for  thought.  It  compares  various  notations  for  writing 
algorithms  for  the  synchronization  of  parallel  processes  by 
comparing  various  solutions  to  the  second  Reader/Writer  Problem 
introduced  in  [1].  The  author  develops  one  solution  using  a 
notation  in  which  critical  sections  are  denoted  explicitly  by  a 
"region  V  do  statement;"  in  addition  one  may  use  (renamed) 
versions  of  Dijkstra's  semaphore  operations  P  and  V.  Since  the 
critical  regions  are  trivially  implemented  using  semaphores,  we 
refer  to  this  as  the  semaphore  notation.  The  other  notation 
allows  one  to  add  a  "when"  condition  to  the  "region  statement"  so 
that  the  statement  in  the  critical  region  will  only  be  executed 
when  a  Boolean  expression  (involving  variables  protected  by  the 
critical  region)  is  true.  This  can  also  be  implemented  using 
semaphores,  and  what  the  author  calls  "a  restructured  form  of  the 
busy  form  of  waiting"  [2].  In  such  an  implementation,  the 
process  will  enter  the  critical  region,  and  execute  the  statement 
if  the  condition  is  true.  If  the  condition  is  false,  it  will 
leave  the  critical  region  and  wait  until  another  process  has 
entered  and  left  the  region  before  entering  and  testing  the 
Boolean  expression  again. 

The  fundamental  problem  with  the  paper  is  that  there  are  too  many 
variables  in  the  comparison.  It  is  not  only  the  notations,  which 
vary  during  the  comparison,  but  the  characteristics  of  the 
solution  vary  as  well.  when  one  solution  appears  much  simpler 
than  another,  one  cannot  tell  whether  it  was  the  notation  that 
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was  responsible  for  the  simplification  or  simply  that  the 
solution  was  different. 

There  are  really  three  solutions  being  compared.  The  first  is 
the  original  solution  to  the  problem  developed  using  semaphores 
in  [1].  The  second  is  the  semaphore  solution  offered  by  the 
author  and  the  third  is  the  solution  using  critical  sections  with 
entry  conditions.  In  the  first  solution  the  semaphores  are  so 
arranged  that  one  never  finds  a  reader  and  a  writer  waiting  on 
the  same  semaphore.  This  has  the  advantage  discussed  in  [3].  In 
the  second  solution  this  restriction  is  relaxed.  The  critical 
section  (or  semaphore) ,  which  is  shared  by  readers  and  writers, 
is  only  that  for  declaring  desire  to  enter  or  leave,  and  is 
presumed  by  the  author  to  be  relatively  short.  Under  that 
assumption  the  probability  of  the  problems  prevented  in  the  first 
solution  actually  occurring  is  low.  In  the  third  solution  all 
waiting  processes  are  waiting  on  the  same  semaphore  or  critical 
section,  and  must  repeatedly  re-enter  the  section  checking  to 
see,  if  they  can  do  what  they  want  to  do.  This  repeated  re-entry 
and  testing  is  avoided  in  both  the  first  and  second  solution  by 
the  use  of  extra  semaphores. 

The  author  draws  strong  conclusions  about  the  superiority  of  the 
conditional  critical  section  notation,  on  the  basis  of  the 
simpler  appearance  of  the  third  solution.  This  reviewer  feels 
that  any  comparison  of  the  notations  is  not  justified,  because 
the  properties  of  the  three  solutions  are  so  different.  The 
notations  can  only  be  compared,  if  the  solutions  are  equivalent. 

In  addition,  the  author  has  made  remarks  comparing  the  two 
semaphore  solutions.  He  considers  the  original  to  be 
"unnecessarily  complicated."  However,  his  semaphore  solution  has 
the  same  number  of  semaphores  (if  we  count  a  critical  second  as  a 
semaphore),  two  additional  variables,  and  twice  as  many 
assignment  statements  as  the  first  solution.  Further,  it  has 
four  loops,  while  the  original  solution  has  none.  Perhaps  the 
author  means  that  he  finds  his  solution  easier  to  understand  than 
the  first  one.  Neither  the  author  nor  his  reviewer  is  qualified 
to  compare  the  two  on  that  basis.  It  is  well  known  that  one's 
own  programs  are  always  easier  to  understand  than  those  written 
by  someone  else.  [CR26,837  D.L.  Parnas] 

REFERENCES 

[1]  Courtois, P. J. ;  Heymans,F. ;  and  Parnas, D.L.;  "Concurrent 
control  with  'readers'  and  'writers.'  Comm. ACM1 4, 1 0 
(Oct. 1971) , 667-668. 

[2]  Hansen, P.E.;  "Structured  Multi-Programming."  Comm.ACM15,7 
(July  1972),  574- 578 ; CR 13 , 1 2  (Dec. 1972),  Rev. 24,238. 

[3]  Courtois, P.J. ;  Heymans,F.;  and  Parnas,  D.L.;  "Comments  on  a 
comparison  of  two  synchronizing  concepts'  by  P.B. Hansen."  Acta 
Informatica  1,4  (1972),  375-376. 
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System; 
pp.  145- 


■■■  Brinch  Hansen,  P. ;  Testing  a  Multiprogramming 
Software  -  Practice  and  Experience  3,2  (April-June  1973) 
1  50. 


■■■  Brinch  Hansen,  P.;  Operating  Systems  Principles;  Prentice- 
Hall,  Inc.,  Englewood  Cliffs,  N.J.  (1973). 

The  reputation  of  this  book's  author  rests  primarily  on  his  work 
in  the  area  of  concurrent  processes.  The  book,  despite  its 
title,  clearly  reflects  this,  and  the  reader  should  be 
forewarned.  There  is  virtually  no  discussion  of  any  of  the 
following  areas,  all  of  which  are  essential  for  a  thorough 
understanding  of  modern  operating  systems:  i)  data  management; 
ii)  physical  file  space  management;  iii)  source/sink  device 
handling;  iv)  command  language;  v)  error  detection,  diagnosis, 
and  recovery;  and  vi)  system  and  resource  protection.  Perhaps 
the  word  "Principles"  in  the  title  is  meant  to  be  a  clue  that 
such  things  would  not  be  discussed. 

The  main  thrust  of  the  book  is  to  define  methods  of  process 
interaction  and  control,  and  to  illustrate  the  value  of  these 
features  in  specifying  process  management,  storage  management, 
scheduling,  and  resource  protection.  A  chapter  is  devoted  to 
each  of  these  subjects. 

The  organization  of  the  book  is  one  of  its  virtues.  The  first 
chapter  presents  an  overview  of  operating  systems  which, 
considering  its  brevity,  is  very  effective.  Its  orientation  is 
consistent  with  the  rest  of  the  book,  i.e.,  there  is  little 
discussion  of  the  areas  enumerated  above.  The  next  two  chapters 
(2  and  3)  describe  the  concepts  involving  processes  and  their 
control.  It  is  primarily  these  concepts  which  are  the 
"Principles"  the  author  analyzes,  though  a  few  others  are 
explored  briefly.  I  consider  these  chapters  plus  the  next  two  (4 
and  5),  on  process  management  and  storage  management,  to  be  the 
real  meat  of  the  book.  The  writing  of  these  sections  is 
exceptionally  well  organized,  and  the  ideas  are  clearly 
presented,  and  illustrated  with  many  examples.  The  chapter  on 
process  management  is  particularly  interesting  in  that  it 
presents  implementations  of  certain  of  the  control  mechanisms 
introduced  earlier.  Chapter  6  on  scheduling  algorithms  is  also 
well  done,  and  does  not  depend  on  the  preceding  chapters.  The 
chapter  on  resource  protection  (7)  does  little  more  than  describe 
the  problem. 

The  final  chapter  (8)  describes  in  some  detail  an  operating 
system  for  the  BC  4000  computer.  This  represents  a  good  example 
of  sound  pedagogy  as  this  chapter  succeeds  in  illustrating  the 
notions  presented  earlier.  The  BC  4000  system  is  well  chosen  to 
serve  this  purpose  for  three  reasons:  i)  the  author  participated 
in  its  design  and  implementation  and  hence  knows  it  well;  ii)  the 
design  is  sound;  and  iii)  the  system  is  small  and  simple  enough 
to  be  described  well  within  the  costraints  of  a  chapter  of  this 
size. 
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Throughout  the  book  consistently  carries  through  the  theme  of 
structured  programming,  with  language-supported  structured 
control  mechanisms,  and  their  use  in  controling  concurrent 
processes.  Informal  arguments  are  provided  for  the  correctness 
of  many  of  the  algorithms.  Because  of  the  structured  mechanisms 
presented,  such  arguments  are  readily  understood  and  convincing. 

The  main  danger  of  the  book,  which  the  author's  commentary  tends 
to  reinforce,  is  that  it  conveys  the  impression  that  operating 
systems  need  not  be  large,  complex  programs.  The  limited  scope 
of  the  book  plus  the  RC4000  system  presented  in  the  last  chapter 
might  lead  one  to  question  where  the  MOL TICS  people,  or  almost 
any  computer  manufacturer,  went  wrong.  I  am  sure  the  people 
responsible  for  these  complex  systems  would  concede  that  by  no 
means  all  of  the  things  in  their  systems  are  right.  On  the  other 
hand,  most  systems  provide,  and  I  think  rightly  so,  more  function 
than  this  book  suggests  may  be  necessary.  Some  of  the  omitted 
facilities,  e.g.,  data  management,  are  virtually  always  required. 
Further,  to  switch  from  a  simple  system  to  one  with  additional 
function,  as  the  requirements  for  the  additional  function  arise, 
is  almost  surely  more  traumatic  than  to  live  from  the  start  with 
the  more  complex  system.  For  this  reason,  a  book  like  Organick's 
The  Multics  Systemf 1 ]  would  be  a  good  companion  to  this  volume. 
It  describes  a  much  more  powerful  system  and  covers,  in  some 
detail,  areas  omitted  from  this  work. 

Despite  the  above  caveat,  this  book  is  of  great  value.  The 
descriptions  of  concurrent  processes,  mechanisms  for  controlling 
them,  and  the  implementations  of  these  mechanisms  are  so  well 
done  as  to,  by  themselves,  justify  the  book.  That  there  is 
additional  good  material  in  the  book  can  be  regarded  as  a  bonus, 
f  CR 26 , 104  D.B.  Lomet] 

REFERENCE 

[1]  Organick, F. I. ;  The  Multics  System:  An  Examination  of  its 
Structure;  MIT  Press,  Cambridge,  Mass.,  CR13,11  (Nov. 1972), 
Rev.  2  4,  104. 


■■■  Brinch  Hansen,  P. ;  A  Programming  Methodology  for  Operating 
System  Design;  IFIP  1974,  Stockholm,  Sweden  (August  1974)  pp. 374- 
397. 

This  is  a  short,  but  very  interesting  paper.  The  author  points 
out  that  "for  most  practical  purposes,  dynamic  process  creation 
is  an  unnecessary  generality  that  complicates  operating  system 
design."  He  also  notes  from  his  earlier  work  on  the  RC4000 
system,  that  up  to  25^  of  the  operating  system  time  may  be  spent 
verifying  the  validity  of  process  interactions  at  run-time. 

The  author  introduces  the  concept  of  a  permanent  process,  which 
is  implemented  as  an  extension  to  PASCAL  (called  Concurrent 
PASCAL).  It  is  proposed  that  an  operating  system  written  in  such 
a  language  will  consist  of  a  fixed  number  of  processes  created 
during  system  loading.  The  syntactic  isolation  of  processes  make 
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it  possible  for  the  compiler  to  check  for  many  possible  errors. 
It  is  also  shown  that  it  is  possible  to  design  a  hierarchical 
operating  system. 

The  points  raised  in  this  paper  are  very  convincing  and  well 
worth  reading.  Hopefully,  future  papers  will  provide  additional, 
and  more  detailed  information.  [CR27,985  S.E.  Madnick] 


sai  Brinch  Hansen,  P. ;  Concurrent  Pascal  Report;  Information 
Science,  Cal.  Institute  of  Technology  (June  1975). 


Brinch  Hansen,  P.;  The  Programming  Language  Concurrent 
PASCAL;  IEEE  Trans.  on  Software  Engineering  1,2  (June  1975) 
pp. 199-207. 


Brinch  Hansen,  P.  ;  Universal  Types  in  Concurrent  PASCAL; 
Information  Processing  Letters  3,6  (July  1975)  pp. 165-166. 


■■■  Brinch  Hansen,  P.;  Concurrent  PASCAL  Machine;  Information 
Science,  Cal.  Institute  of  Technology  (October  1975). 


■■■  Brinch  Hansen,  P. ;  A  Real-time  Scheduler;  Information 
Science,  Cal.  Institute  of  Technology  (Nov.  1975). 


■■■  Brinch  Hansen,  P. ;  The  Job  Stream  System;  Information 
Science,  Cal.  Institute  of  Technology  (Jan.  1976). 


a  a  a  Brinch  Hansen,  P.;  The  Solo  Operating  System;  Software 
Practice  and  Experience  6,2  (April-June  1976)  pp. 141-205. 


■ ■ ■  Burstall,  R.M.,  and  Landin,  P.J. ;  Programs  and  Their  Proofs: 
An  Algebraic  Approach;  Machine  Intelligence  5  (1969)  pp. 17-43. 


aa«  Burstall,  R.M.;  Writing  Search  Algorithms  in  Functional  Form; 
in  Machine  Intelligence  3,373-385.  See  main  entry  CR10,1 
(Jan. 1969) ,  Rev. 1 5,918. 

The  paper  deals  with  the  problem  of  searching  through  a  tree 
graph  for  a  node  which  has  a  particular  property.  This  problem 
frequently  arises  in  artificial  intelligence  applications,  for 
example,  in  searching  for  a  desirable  position  in  a  board  game. 
Three  alternate  search  algorithms  are  presented,  but  attention  is 
focused  on  a  method  first  described  by  Doran  and  Michie[1].  It 
appears  to  me  that  the  Doran  and  Michie  method  is  itself  subsumed 
by  a  method  of  finding  the  shortest  route  from  one  point  to 
another  in  any  directed  graph.  The  more  general  method,  credited 
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to  Dantzig,  appears  in  standard  operations  research  texts  (Ford 
and  Fulkerson) .  The  main  point  of  the  paper  is  said  to  be  a 
demonstration  that  the  Doran  and  Michie  algorithm  can  be 
programmed  elegantly  by  introducing  some  new  constructs  into  an 
ALGOL-like  language.  This  point  is  made,  although  my  own  opinion 
is  that  the  more  general  algorithm  is  easily  programmed  in  ALGOL. 
(I  have  used  it  as  a  class  exercise.) 

The  paper  is  not  clearly  written.  I  found  Section  5  almost 
incomprehensible,  so  my  review  may  have  missed  something. 
Examples  are  given  using  the  language  ISWIM  [2]  which  is  hardly  a 
standard  programming  language.  [CR 16,426  E.B.  Hunt] 
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■■■  Burstall,  R.M.;  Some  Techniques  for  Proving  Program 
Correctness  of  Programs  Which  Alter  Data  Structure;  Machine 
Intelligence  7  (1972)  pp. 23-50. 

The  paper  extends  Floyd's  method  to  programs  which  alter  data 
structures  such  as  arrays,  linear  lists,  or  binary  trees.  The 
simple  assignment  axiom  being  insufficient  a  family  of  distinct, 
specialized  rules  for  assignment  is  introduced.  These  rules 
depend  on  the  kind  of  data  structure  which  is  altered,  and  on  the 
selection  or  construction  used  as  destination  of  the  assignment; 
they  are  formulated  in  terms  of  a  "change  set"  which  defines 
identifiers  whose  meaning  is  changed  by  the  assignment.  A  list¬ 
processing  machine  and  its  states  are  formalized  in  a  first-order 
language;  this  formalization  is  applied  to  the  proof  of  a  flow¬ 
chart  program  reversing  linear  lists.  The  result  of  the 
experiment  being  "long  and  tedious,"  and  the  proofs  being  "guite 
long  and  very  boring,"  a  better  formalization  is  defined,  based 
on  a  graph-*like  representation  of  the  data  structure.  The 
assignment  rules  are  reformulated  in  terms  of  the  new 
formalization  and  the  example  is  then  proved  cleanly  and 
completely.  The  paper  continues  by  generalizing  the  same  methods 
for  binary  trees,  as  an  example  of  more  complex  data  structures, 
using  the  techniques  of  the  category  theory. 

The  proposed  assignment  rules  are  sensible  extensions  of  the 
standard  assignment  axiom,  but  they  are  very  ad  hoc;  how  many 
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such  rules  would  be  needed  in  the  case  of  freely  composed 
hierarchical  data  structures?  One  would  prefer  a  more  general 
assignment  rule  whose  structure  is  not  more  complex  than  a 
unified  method  for  defining  various  data  structures.  The  various 
formalizations  presented  are  essentially  logical  formulations  of 
implementation-oriented  representations.  The  author  makes  a 
valid  point  by  showing  how  both  the  usefulness  and  the 
readability  of  a  formalization  depend  on  the  elimination  of 
unessential  features.  The  use  of  the  category  theory  may  be  an 
interesting  exercise,  as  is  usual  with  that  theory,  but  here  it 
brings  no  new  results,  just  a  simple  generalization  of  the 
previous  ones;  moreover,  its  use  for  proving  a  tree-reversing 
program  is  inconclusive,  because  this  program  is  recursive  and  is 
easily  verified  by  an  immediate  application  of  recursion 
induction.  fCR25,707  M.  Sintzoff  ] 


■■■  Burstall,  R.M. ;  Algebraic  Description  of  Programs  with 
Assertions,  Verification  and  Simulation;  ACM  Conference  on 
Proving  Assertions  About  Programs  (1972)  pp.7-14. 

mmm  Burstall,  R.M.,  with  Darlington,  J.;  A  System  Which 
Automatically  Improves  Programs;  Proc.  3rd  International 
Conference  on  AI,  S.R.I.  (1973)  pp. 537-542. 


•  a  a  Burstall,  R.M.,  and  Thatcher,  J.W.;  The  Algebraic  Theory  of 
Recursive  Program  Schemes;  Category  Theory  Applied  to  Computation 
and  Control,  San  Francisco,  Cal.,  25-26  February  1974,  Springer- 
Verlag,  Berlin  (1975)  pp. 126-131. 

■  a ■  Burstall,  R.M.,  and  Darlington,;  Some  Transformations  for 
Developing  Recursive  Programs;  International  Conference  on 
Reliable  Software,  SIGPLAN  Notices  10,6  (June  1975)  pp. 465-472. 


a  a  a  Buxton,  J.N.;  The  Nature  and  Implications  of  Software 
Engineering;  in  Hugo,  J.S.(ed.),  The  Fourth  Generation,  Infotech, 
Ltd.,  Berkshire,  England  (1971)  pp. 227-238. 


a  a  a  Buxton,  J.N.;  Proc.  of  the  1974  CERN  School  of  Computing, 
Godysund,  Norway,  11-24  August,  1974;  Geneva,  Swit zerland : CERN 
(1974)  pp. 394-401. 


■aa  Buxton,  J.N.,  Naur,  P.,  and  Randell,  B.;  Software 
Engineering;  Petrocelli  (1975). 


■■a  Dahl,  O.-J.,  and  Hoare,  C.A.R.;  Hierarchical  Program 
Structures;  In  Dahl,  et  al..  Structured  Programming,  Academic 
Press  (1972)  pp.  175-220. 
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(1974)  pp. 426-435. 
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pp. 157-174. 
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C  ACM  5,11  (May  1968)  pp. 341-346. 
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Program  Correctness;  PIT  8,3  (1968)  pp. 174-186. 


aaa  Dijkstra,  E.W.  ;  Concern  for  Correctness  as  a  Guiding 
Principle  for  Program  Composition;  in  Hugo,  J.S.  (ed.).  The 
Fourth  Generation,  Infotech,  Ltd.,  Berkshire,  England  (1971) 
pp. 357-367. 


aaa  Dijkstra,  E. W. ;  A  Short  Introduction  to  the  Art  of 
Programming;  Technological  University,  Eindhoven,  EWD316  (August 
1 971)  . 


aa»  Dijkstra,  E.W. ;  On  a  Methodology  of  Design;  in  MC-25 
Informatica  Symposium,  Mathematisch  Centrum,  Amsterdam  (1971) 
4. 1-4.  10. 

In  this  paper,  which  appears  to  be  the  text  of  an  address,  the 
author  gives  his  views  on  the  development  of  a  general 
methodology  for  design  or  problem  solving.  Since  the  author  is 
an' expert  on  the  methodology  of  program  design,  he  is  well 
qualified  to  speak  on  this  subject.  He  suggests  that  we  must 
also  develop  methodologies  for  solving  problems  with  complex 
solutions.  In  this  regard,  he  suggests  that  the  study  of 
methodologies  for  program  design  may  be  relevant  to  design 
methodologies  in  general,  since  programs  are  very  complicated 
mechanisms  to  design.  In  the  case  of  a  complex  program  systems, 
the  design  can  be  subdivided  into  intermediate  levels  to  bridge 
the  gap  between  the  environment  in  which  the  final  solution  or 
system  is  produced  and  the  environment  of  the  hardware  machine. 
The  introduction  of  levels  is  necessary  because  the  hardware 
machine  environment  is  not  suitable  for  formulating  the  program 
system  directly.  An  example  of  this  approach  is  the  design  of 
the  THE  Multiprogramming  System[ 1  ].  The  author  points  out  that 
the  division  into  levels  is  similar  to  methods  for  explaining 
complex  natural  systems,  such  as  in  chemistry  where  molecular 
structures  are  explained  in  terms  of  atoms,  atoms  are  explained 
in  terms  of  nuclei  and  electrons,  etc.  The  structure  of  each 
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level  is  explained  in  terms  of  the  level  below  it  and,  very 
importantly,  the  description  of  each  level  is  precise. 

In  program  design,  there  is  the  requirement  that  the  program 
solution  be  demonstrated  to  be  correct,  or  in  a  sense  a  "good" 
design.  The  author  suggests  that  we  find  methodologies  that  aid 
not  merely  in  finding  solutions  to  problems  but  also  in 
demonstrating,  using  rigorous  arguments,  that  these  solutions 
satisfy  the  requirements  of  the  problem  statement. 

The  author's  expectations  for  developments  in  design 
methodologies  over  the  next  ten  years  include  the  development  of 
better  methods  for  formulating  correctness  arguments,  improved 
understanding  of  the  relations  among  intermediate  and  final 
design  levels,  the  development  of  the  ability  to  judge  the 
adequacy  of  tools  such  as  programming  languages  in  problem 
solving,  the  ability  to  predict  the  consequences  of  a  design,  and 
the  expectation  that  it  will  be  possible  to  teach  design  methods. 

The  paper  suffers  somewhat  from  a  tendency  of  the  author  to 
overstate  his  case  as,  for  example,  in  his  justification  of  the 
relevance  of  programming  methodology  to  general  design 
methodology  where  he  states  "Over  the  last  decades  the  most 
complicated  things  designed  to  do  something  have  been 
programs;...”  Such  statements  tend  to  distract  the  reader  from 
the  important  theme  of  this  paper,  which  is  the  importance  and 
necessity  for  study  of  the  design  process.  [CR25,465  T.H.  Bredt] 

l 1  ]  Di jkstra, E.W. ;  "The  Structure  of  the  'THE'  Multiprogramming 
System.”  CACM  5,11  (May  1968),  341-346. 


Dijkstra,  E. W. ;  A  Class  of  Allocation  Strategies  Inducing 
Bounded  Delays  Only;  SJCC  1972  (1972)  pp. 933-936. 

This  paper  shows  that  a  set  of  M  processes  can  share  a  resource 
R;  it  presents  an  algorithm  which  guarantees  that  none  of  those 
processes  must  wait  for  more  than  M-1  other  processes  to  use  R 
before  it  can  gain  access  to  R.  The  access  control  algorithm 
consists  of  an  ENTRY  inspection  procedure  which  is  invoked  when  a 
process  requests  the  use  of  R,  and  an  EXIT  inspection  procedure 
which  is  invoked  when  a  process  wishes  to  relinquish  use  of  R. 
Both  the  ENTRY  and  EXIT  inspections  can  (zero  or  more  times)  add 
a  waiting  process  to  the  set  of  resource  R  users.  The  ENTRY 
inspection  either  permits  a  requesting  process  P  to  use  R,  or 
adds  P  to  the  set  of  processes  waiting  to  use  R,  when  no  other 
process  is  doing  so.  The  EXIT  inspection  must  insure  that  at 
least  one  of  the  set  of  waiting  processes  is  granted  access  when 
the  last  user  of  R  relinquishes  use  of  R. 

The  paper  itself  provides  much  better  reading  than  this  rather 
dry  review,  especially  because  of  the  terminology  and  anecdotes 
that  the  author  uses  to  present  a  lucid  picture  of  the  problem  he 
attacks.  [CR23,952  M.L.  Graham] 
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Dijkstra,  E. W. ;  Reliability  of  Programs;  Infotech  State-of- 
the-Art  Report  no. 7  (1972)  pp. 217-232. 


■■■  Dijkstra,  E.W.;  The  Humble  Programmer;  CACM  15,10  (October 
1972)  pp. 859-866. 

This  is  a  paper  on  the  philosophy  of  computer  programming  which 
should  be  read  and  re-read  at  least  once  every  year  by  everyone 
with  programming  projects.  The  flavor  of  the  lecture  can  be 
gleaned  from  some  guotes; 

...In  retrospect  we  must  rate  FORTRAN  as  a  successful  coding 
technique,  but  with  very  few  effective  aids  to  conception, 
aids  which  are  now  so  urgently  needed  that  time  has  come  to 
consider  it  out  of  date.  The  sooner  we  can  forget  that 
FORTRAN  ever  existed,  the  better,  for  as  a  vehicle  of  thought 
it  is  no  longer  adequate:  it  wastes  our  brainpower,  and  it 
is  too  risky  and  therefore  too  expensive  to  use.  FORTRAN'S 
tragic  fate  has  been  its  wide  acceptance,  mentally  chaining 
thousands  and  thousands  of  programmers  to  our  past  mistakes. 
I  pray  daily  that  more  of  my  fellow  programmers  may  find  the 
means  of  freeing  themselves  from  the  curse  of  compatibility. 

...When  FORTRAN  has  been  called  an  infantile  disorder,  full 
PI/I,  with  its  growth  characteristics  of  a  dangerous  tumor, 
could  turn  out  to  be  a  fatal  disease. 

...We  must  not  forget  that  it  is  not  our  business  to  make 
programs;  it  is  our  business  to  design  classes  of 
computations  that  will  display  a  desired  behaviour. 

...It  has  been  suggested  that  there  is  some  law  of  nature 
telling  us  that  the  amount  of  intellectual  effort  needed 
grows  with  the  square  of  program  length.  But,  thank 
goodness,  no  one  has  been  able  to  prove  this  law.  And  this 
is  because  is  need  not  be  true...  I  tend  to  the  assumption-- 
up  till  now  not  disproved  by  experience — that  by  suitable 
application  of  our  powers  of  abstraction,  the  intellectual 
effort  required  to  conceive  or  to  understand  a  program  need 
not  grow  more  than  proportional  to  program  length. 

...Even  if  we  know  how  to  educate  tomorrow's  professional 
programmer,  it  is  not  certain  that  the  society  we  are  living 
in  will  allow  us  to  do  so.  The  first  effect  of  teaching  a 
methodology — rather  than  disseminating  knowledge--is  that  of 
enhancing  the  capacities  of  the  already  capable,  thus 
magnifying  the  difference  in  intelligence.  In  a  society  in 
which  the  educational  system  is  used  as  an  instrument  for  the 
establishment  of  a  homogenized  culture,  in  which  the  cream  is 
prevented  from  rising  to  the  top,  the  education  of  competent 
programmers  could  be  politically  unpalatable, 
f  CR24 , 552  F.  Gruenberger] 
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Dijkstra,  E.  W. ;  Notes  on  Structured  Programming;  in  Dahl,  et 
al. ,  Structured  Programming,  Academic  Press  (1972)  pp.1-82. 


■■■  Dijkstra,  E.W.;  Hierarchical  Ordering  of  Sequential 
Processes;  in  Hoare  and  Perrott  (eds.).  Operating  Systems 
Techniques,  Academic  Press  (1972)  pp. 72-93. 

This  paper  is  a  well-organized  exposition  of  the  rationale  and 
use  of  parallel  processes  and  layered  structure  in  operating 
systems.  Although  there  is  little  new  material  in  the  paper,  the 
development  of  the  topics  is  so  reasoned  and  logical  that  the 
paper  should  be  of  wide  interest. 

The  author  traces  the  evolution  of  parallel  processes  from  an 
historical  consideration  of  I/O  channels  and  interrupts.  He 
suggests  that  layering  is  a  natural  consequence  of  attempts  to 
make  the  nonde terminist ic  machine  (in  which  many  concurrent, 
asynchronous  operations  are  taking  place)  into  a  deterministic 
problem-solving  automaton  for  each  user.  He  then  considers  the 
most  suitable  primitive  operations  to  be  included  in  the  lowest 
layer  of  the  system.  These  include  handling  interrupts  (so  that 
higher  layers  need  never  know  of  their  existence),  interprocess 
communication  and  interprocess  synchronization. 

The  author  then  deals  in  turn  with  mutual  exclusion,  the 
development  of  the  semaphore  and  a  proof  of  its  correctness  and 
critical  regions,  conflicts  for  use  of  scare  resources,  and  the 
use  of  "secretary"  processes  to  handle  and  to  centralize  the 
communication  and  synchronization  tasks  for  other  processes. 
(Unfortunately,  the  author  identifies  the  secretary  processes  as 
female;  in  keeping  with  equal  rights,  this  reviewer  prefers 
Hoare* s  term  "monitor"  for  these  processes.) 

The  appearance  of  the  monitor  concept  is  significant  since  it 
clears  up  what  had  seemed  a  salient  objection  to  the  use  of 
semaphores  for  synchronization  and  mutual  exclusion.  There  are 
usually  quite  a  few  semaphores  in  a  system  (one  for  each  critical 
region),  and  early  work  on  the  semaphore  implied  that  it  would  be 
best  used  for  distributed  (as  opposed  to  centralized)  control  of 
processes.  Consequently,  at  least  one  operating  system  of  which 
this  reviewer  has  knowledge  had  great  difficulty  in  cleaning  up 
after  an  asynchronous  interrupt  (illegal  instruction,  attention 
interrupt,  etc.)  precisely  because  no  process  knew  where  all  the 
semaphores  in  the  system  were  located  and  why  they  were  there. 
With  a  monitor  process  available  on  each  layer  of  the  system, 
this  problem  can  be  largely  alleviated. 

I  would  especially  recommend  this  paper  to  students  in  software 
architecture,  software  engineering,  operating  systems,  and 
program  semantics  courses.  [CR26,377  G.N.  Cederquist  ] 
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■■■  Dijkstra,  E.W.;  A  Simple  Axiomatic  Basis  for  Programming 
Language  Constructs;  Technological  University,  Eindhoven,  EWD372 
(1973)  . 


■■■  Dijkstra,  E.W. ;  Self- Stab iliz ing  Systems  In  Spite  of 
Distributed  Control;  CACM  17,11  (November  1974)  pp. 643-644. 

In  this  paper  the  author  describes  a  design  of  a 
" self stabilizing"  system  accomplishing  the  synchronization  task 
between  loosely  coupled  cyclic  sequential  processes,  when  the 
processes  do  not  share  a  commonly  accessible  store  in  which  "the 
current  system  state"  is  recorded. 

The  author  considers  the  case  where  the  "current  system  state"  is 
recorded  in  variables  distributed  over  the  various  processes, 
and,  further,  the  communication  facilities  are  limited  so  that 
each  process  can  only  exchange  information  with  "its  neighbors"  - 
a  small  subset  of  the  total  set  of  processes.  This  leads  to  the 
complication  that  the  behaviour  of  a  process  can  only  be 
influenced  by  that  part  of  the  total  current  system  state 
description  that  is  available  to  it.  Such  systems  with 
"distributed  control"  require  that  local  actions  taken  on  account 
of  local  information  must  accomplish  a  global  objective  as,  say, 
the  system  as  a  whole  should  be  in  a  legitimate  state. 

The  author  suggests  a  solution  to  the  problem  of  designing  a 
"self-stabilizing"  system,  i.e.,  the  system  which  is  sure  to  be 
in  a  legitimate  state  after  a  finite  number  of  moves,  considering 
N+1  machines  with  finite  states,  placed  one  at  each  node  of  a 
connected  graph  in  which  the  majority  of  the  possible  edges  are 
missing.  Solutions  with  K  state  machines  (K>N) ,  with  four  state 
machines  and  with  three  state  machines  have  been  dealt  with. 
[ CR28 ,127  N.V.K.  Rao] 


■  Dijkstra,  E.W.;  Synchronization  and  Sequencing;  Informatic 
(Netherlands)  16,12  (Dec.  1974)  pp. 643-645  (In  Dutch). 


■■■  Dijkstra,  E.W.;  Guarded  Commands,  Non-determinacy  and  a 
Calculus  for  the  Derivation  of  Programs;  International  Conference 
on  Reliable  Software,  SIGPLAN  Notices  10,6  (June  1975)  p.2. 


■■■  Dijkstra,  E.W.;  Correctness  Concerns  and.  Among  Other  Things, 
why  They  are  Resented;  International  Conference  on  Reliable 
Software,  SIGPLAN  Notices  10,6  (June  1975)  pp. 546-550. 


Dijkstra,  E.W.; 
(1976)  . 


A  Discipline  of  Programming;  Prentice-Hall 
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Gries,  D. ;  Programming  by  Induction;  Information  Processing 
Letters  1,3  (1972)  pp. 100-107. 


■■■  Gries,D.,  with  Conway, R.;  An  Introduction  to  Programming:  A 
Structured  Approach  Using  PL/I  and  PL/C.  Winthrop  Publ.  Inc., 
Cambridge,  Mass.,  1973,  460  pp. 

In  reviewing  this  book  one  is  struck  immediately  with  the  value 
of  the  material  contained  in  Parts  II  and  III,  which  deal  with 
program  development  and  confirmation  of  program  correctness. 
Indeed,  this  book  marks  the  first  entry  into  the  literature  for 
beginning  programmers  (computer  scientists?)  that  attempts  to 
convey  the  some  of  the  science  of  programming  while  still  giving 
the  reader  a  firm  grasp  of  fundamentals.  The  viewpoint  of  the 
authors  is  generally  a  "how-to-do-it" ,  with  examples  guiding  the 
way.  Perhaps  the  flavor  of  this  book  is  best  summed  up  in  the 
following  statement  from  the  text:  "Use  a  GO  TO  only  when  the 
alternative  is  even  more  awkward." 

On  the  other  hand  this  reviewer  is  less  than  satisfied  with  the 
topical  material  of  this  book.  The  authors  indicate  that  between 
the  emphasis  on  approach  and  on  the  details  of  the  particular 
language,  the  approach  is  more  important.  However,  the  book 
presents  details  of  a  relatively  complex  programming  language,  a 
programming  style,  and  in  addition  he  discusses  three  different 
applications.  The  reviewer's  dissatisfaction  is  not  with  the 
stated  emphasis,  but  rather  with  the  question  of  where  such 
topics  belong,  and  in  their  present  association,  where  such  a 
book  might  fit  in  the  curriculum.  For  our  first  course,  the  book 
is  too  specific  in  programming  and  too  diverse  in  topics;  for  the 
second  course,  or  beyond,  the  text  contains  too  much  irrelevant 
material . 

In  conclusion,  I  would  say,  however,  that  this  book  deserves  a 
careful  examination  by  those  of  us  involved  in  teaching 
programming  techniques.  If  the  student  is  not  introduced  very 
early  in  the  educational  process  to  the  material  contained  in 
Parts  II  and  III,  then  we  are  not  serving  the  best  interests  of 
the  student.  [CR26,476  P.L.  Fisher] 


Gries,  D. ;  Describing  an  Algorithm  by  Hopcroft;  Acta 
Informatica  2  (1973)  pp. 97-109. 


■■■  Gries,  D.;  What  Should  We  Teach  in  an  Introductory 
Programming  Course;  Proc.  of  the  4th  Symposium  on  Computer 
Science  Education,  SIGCSE  Bulletin  6  (February  1974)  pp. 81-89. 


■■■  Gries,  D. ;  On  Structured  Programming  -  A  Reply  to  Smoliar; 
CACM  17,11  (November  1974)  pp. 655-657. 
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■■■  Gries,  D. ,  with  Conway,  R.  ;  An  Introduction  to  Programming; 
Winthrop,  Cambridge,  Mass.  (1  975). 


Gries,  D.,  and  Conway,  R.;  An  Introduction  to  Programming:  A 
Structured  Approach  Using  PL/I  and  PL/C-7  (Second  edition) ; 
Winthrop  Publishers,  Inc.,  Cambridge,  Mass.,  (1975)  509pp. 

This  textbook  is  designed  as  a  first  course  in  computer 

programming.  It  uses  PL/I,  although  with  some  reservations 

because  it  is  the  most  suitable  language  for  the  "structured 
programming,"  "top  down"  approach  favored  by  the  authors.  The 
examples  are  drawn  from  both  scientific  and  commercial 

applications,  but  they  are  short  and  pedagogic  and  do  not  give 
the  student  a  feeling  for  what  a  complete  problem  involves. 
There  are  worthwhile  chapters  on  performance  evaluation,  program 
testing,  and  confirmation  of  correctness,  topics  usually  omitted 
from  texts  of  this  nature.  The  book  is  reproduced  from 

typewritten  pages  and  is  quite  wordy;  but  it  does  give  the 
student  a  feeling  for  program  structure,  not  just  language  and 
syntax.  [CR29,672  K.  Fuchelj 


■■■  Gries,  D. ,  with  Conway,  R.;  Primer  on  Structured  Programming; 
Winthrop,  Cambridge,  Mass.  (1976). 


■■■  Gries,  D.,  with  Zimmerman,  E.C.  and  Conway,  R. ;  A  Primer  on 
Pascal;  Winthrop,  Cambridge,  Mass.  (1976). 


■a«  Gries,  D.;  An  Exercise  in  Proving  Parallel  Programs  Correct; 
Summer  School,  Marktoberdorf ,  Germany  (1976). 


■■■  Gries,  D. ;  Some  Comments  on  Programming  Language  Design;  in 
Schneider,  H.-J.  and  Nagl,  M.(ed.),  Programmiersprachen,  4. 
Fachtagung  der  GI,  Springer-Verlag,  Heidelberg  (1976)  pp. 235-252. 


■■■  Gries,  D. ,  with  Gehani,  N. ;  Some  Ideas  on  Data  Types  in  High 
Level  Languages;  Proc.  of  Conference  on  Data:  abstraction, 
definition,  and  structure.  Salt  Lake  City  (March  1976).  ??? 


■■■  Gries,  D. ,  and  Owicki,  S. ;  Verifying  Properties  of  Parallel 
Programs:  An  Axiomatic  Approach;  CACM  19  (May  1976)  pp. 279-285. 


■■■  Gries,  D. ;  An  Illustration  of  Current  Ideas  on  the  Derivation 
of  Correctness  Proofs  and  Correct  Programs;  IEEE  Trans.  on 
Software  Engineering  (December  1976). 
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■■■  Gries,  D.  ,  with  Owicki,  S.  ;  An  Axiomatic  Proof  Technique  for 
Parallel  Programs  I;  Acta  Inf orma tica ,  6  (1976)  pp.  319-340. 

■  ■■  Gries,  D.  ;  The  Assignment  Statement;  submitted  to  LDRS. ?? ? 


■■■  Gries,  D. ;  Current  Ideas  on  Programming  Methodology;  in 
Wegner  and  Wulf  (ed.),  The  Impact  of  Research  on  Software 
Methodology,  to  be  published. 


Gries,  D. ;  The  Use  of  Comments  on  Programming;  Submitted  to 
CACM. ??? 

■■■  Hoare,  C.A.R.;  Record  Handling;  in  Symbol  Manipulation  and 
Techniques,  pp. 262-284.  See  main  entry  CR9,8  (August  1968), 
Rev. 1 4,970. 

It  is  very  good  to  see  these  NATO  Summer  School  notes  from  1966 
in  a  more  widely-available  form.  This  article  presents  a  clear 
introduction  to  the  basics  of  records  and  fields  as  a  data 
structuring  technique  (see  also  [1]).  The  principal  ideas  may  be 
roughly  summarized  as  follows:  A  record  class  declaration 
establishes  a  generic  type  of  record  with  any  number  of  named 
fields  which  may  contain  values  of  various  declared  types.  Many 
specific  instances  of  that  type  of  record  may  then  be  created  in 
which  the  fields  contain  specific  values  of  the  allowed  types.  A 
reference  (or  pointer)  to  a  record  of  a  specific  class  is  an 
allowed  data  type,  allowing  the  composition  of  elaborate  data 
structures  from  interconnected  records.  A  record  class  name 
written  as  a  function  call  causes  a  new  record  of  that  type  to  be 
created  and  initialized,  and  the  value  of  the  call  is  a  reference 
to  the  newly-created  record.  A  composite  record  class  may  be 
declared  to  consist  of  a  number  of  mutually  exclusive  subclasses; 
program  variables  or  fields  of  records  may  be  constrained  by 
declaration  to  reference  a  composite  class,  i.e.,  only  records  of 
any  one  of  the  designated  subclasses.  In  this  way,  for  example, 
properties  of  "person”  can  be  manipulated  without  regard  to 
fields  peculiar  to  "son",  "parent",  "cousin",  etc.,  all  of  which 
may  be  subclasses  of  the  composite  class  "person".  The  paper 
includes  several  good  examples  which  are  worked  out  in  sufficient 
detail  to  make  the  concepts  come  alive  for  readers  who  have  not 
previously  been  exposed  to  such  an  approach  to  data  structuring. 

The  paper  is  clearly  written,  well  motivated,  and  should  become 
one  of  the  primary  references  for  work  in  this  field.  The  reader 
is  warned,  however,  that  the  concepts  really  are  much  broader 
than  this  introductory  paper  indicates,  and  the  transcribed 
discussion  which  accompanies  the  paper  seems  to  cloud  rather  than 
clarify  some  of  the  important  additional  issues.  Since  these 
matters  are  fast  becoming  one  of  the  major  thrusts  of  computer 
programming  and  are  incorporated  into  the  forthcoming  ALGOL68 
language,  a  few  additional  remarks  are  in  order.  Evidently  the 
author  himself  did  not  present  the  paper,  since  the  discussion  is 
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led  by  B.  Mailloux.  However,  discussion  does  close  with  two 
brief  notes  by  the  author  "added  in  proof". 

R eference  s 

[11  Wirth,N.;  and  Hoare,  C.A.R.;  "A  Contribution  to  the 
Development  of  ALGOL."  Comm  ACM  9,6  (June  1966),  413-431;  CR 
Rev. 15,980.  [CR15,984  D.T.  Ross] 


■■■  Hoare,  C.A.R.;  An  Axiomatic  Approach  to  Computer  Programming; 
C  ACM  12,10  (October  1969)  p.576. 

This  paper  expounds  the  notion  that  since  computer  programs  can 
be  treated  as  mathematical  objects,  they  are  amenable  to  the 
ordinary  methods  of  mathematical  discourse,  and  that  the 
application  of  these  methods  will  yield  useful  properties  of 
programs.  First,  the  author  presents  a  collection  of  axioms  of 
arithmetic  (not  claimed  to  be  complete)  that  apply  to  three 
possible  treatments  of  overflow:  the  result  is  undefined;  the 
result  is  fixed  maximum;  and,  the  result  is  obtained  through 
modulo  arithmetic.  Unfortunately,  even  in  this  simple  example, 
the  results  are  confined  to  nonnegative  numbers.  In  the  second 
part  of  the  paper,  the  axioms  of  program  execution  are  presented; 
here  the  author  closely  follows  Floyd.  Next,  there  is  a 
discussion  of  proofs  of  program  correctness  and  their  usefulness; 
and  the  paper  concludes  with  a  discussion  of  formal  language 
definition. 

This  is  an  interesting  but  essentially  expository  paper, 
worthwhile  mainly  for  its  clear  presentation  of  some  essential 
concepts  in  the  mathematical  treatment  of  computer  programs. 
[  CR18,328  P.W.  Abrahams] 


■■■  Hoare,  C.A.R.;  Data  Structures  in  a  Two- level  Store;  in  Proc. 
I FIP  Congress  1968,  Invited  Papers,  111-117.  See  main  entry 
CR'9,11  (Nov.  1968),  Rev.  1  5,489. 

Most  computers  have  at  least  two  levels  of  storage:  a  fast¬ 
working  store,  generally  magnetic  cores;  and  a  slower  high-volume 
backing  store,  which  usually  consists  of  magnetic  tape,  magnetic 
disks,  magnetic  drums,  or  a  combination  of  the  three.  Large 
computing  jobs  must  be  divided  into  sections,  each  small  enough 
to  fit  into  the  working  store,  and  each  as  self-contained  as 
possible  and  involving  a  minimum  of  reference  to  other  parts  of 
the  job  held  on  the  backing  store. 

The  paper  is  concerned  with  ways  of  selecting  the  size  and 
structure  of  the  sections  of  data  and  program  so  that  the 
transfers  will  be  efficient  and  simple  to  program.  The  proposals 
are  not  intended  to  apply  to  commercial  data  processing;  the 
examples  given  refer  to  the  storage  and  modification  of  data 
which  describes  the  logical  operation,  packaging,  and  connections 
of  digital  electronic  apparatus.  The  transfers  are  written  in 
ALGOL  and  involve  a  few  additions  to  the  basic  language  to 
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implement  the  data  transfers.  The  author* s  proposals  are 
difficult  to  implement  on  a  machine  which  has  no  paging  facility 
and  impose  some  restrictions  on  the  use  of  the  backing  store,  but 
they  constitute  a  useful  addition  to  basic  ALGOL  for  some  classes 
of  large  problems.  [CR16,715  J.C.  Cluley] 


■ao  Hoare,  C.A.R.;  Procedures  and  Parameters:  An  Axiomatic 
Approach;  Symposium  on  Semantics  of  Algorithmic  Languages, 
Springer-Verlag,  Berlin  (1971)  pp. 102-116. 

Procedures  of  symbolic  logic  are  used  to  formulate  an  axiomatic 
approach  to  programming  language  construction.  It  is  shown  that 
languages  formulated  in  this  way  have  several  advantages,  one  of 
which  is  ease  of  error  detection.  [CR23,647  A.D.  Booth] 


Hoare,  C.A.R.;  Proof  of  a  Program:  FIND;  CACM  14,1  (January 
1971)  pp.  39-45. 

This  paper  consists  of  a  thorough  proof  of  the  correctness  and 
termination  of  a  particular  program.  The  approach  taken  is 
variously  referred  to  as  the  method  of  invariants,  general 
snapshots  or  inductive  assertions.  The  program  itself  is  quite 
short  and  implements  an  intuitively  appealing  algorithm,  but  is 
not  trivial  (it  contains  nested  looping  to  depth  three)  in  the 
sense  that  a  certification  of  some  variety  is  certainly  required 
to  convince  one  of  its  correctness.  The  author  uses  the  notation 
of  the  predicate  calculus  and  presents  the  proof  through  a  series 
of  18  lemmas  (for  about  a  12  line  program).  Still,  several 
significant  aspects  are  treated  only  informally.  While  the 
importance  of  formal  proofs  of  program  properties  is  now 
generally  conceded,  a  reading  of  this  paper  seems  likely  to 
convince  the  reader  of  the  validity  of  an  earlier  comment  by  the 
author,  "program  proving,  certainly  at  present,  will  be  difficult 
even  for  programmers  of  high  caliber;  and  may  be  applicable  only 
to  quite  simple  program  dsigns".  [CR22,296  A.C.  Fleck] 


■■■  Hoare,  C.A.R.,  with  Foley,  M. ;  Proof  of  a  Recursive  Program 
Quicksort;  Computer  J  14,4  (November  1971)  pp. 391-395. 


■  Hoare,  C.A.R.;  Proof  of  a  Structured  Program:  The  Sieve  of 
Eratosthenes;  Computer  J.  15  (November  1972)  pp. 321-325. 


■■■  Hoare,  C.A.R.;  The  Quality  of  Software;  Software-Practice  and 
Experience  2,2  (April-June  1972)  pp. 103-105. 


■  ■■  Hoare,  C.A.R.  and  Perrott,  R. N.  (eds.);  Operating  Systems 
Techniques;  Proc.  of  Seminar  at  Queens  University,  Belfast, 
Academic  Press,  London  (1972). 
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The  papers  in  this  volume  have  been  individually  reviewed;  each 
is  cross-referenced  to  this  main  entry  to  provide  complete  source 
and  citation  data. 

See  25,652,  25,653;  25,654;  25,655;  25,656;  25,657;  25,658; 
25,659;  25,660;  25,661;  25,662. 

This  book  reports  the  proceedings  of  an  International  Seminar  on 
Operating  Systems  Techniques  held  at  the  Queen's  University 
Belfast  between  30th  August  and  3rd  September  1971.  The  Seminar 
was  sponsored  jointly  by  International  Computers  Limited  and  the 
Advanced  Computer  Technology  Project,  by  whose  kind  permission 
the  book  is  published. 

The  seminar  formed  a  part  of  a  continuing  research  project  ...  to 
investigate,  classify  and  evaluate  the  practical  techniques  which 
have  been  used  in  the  implementation  of  successful  operating 
systems.  It  is  hoped  to  relate  each  technique  to  its  objective, 
and  to  the  range  of  circumstances  in  which  it  is  applicable;  and 
thus  produce  a  reliable  guide  upon  which  an  operating  system 
designer  can  base  his  decisions. 

...This  study  will  also  be  interesting  to  the  users  of  operating 
systems;  it  may  help  them  to  evaluate  the  techniques  adopted  by 
rival  systems,  to  select  the  best  options  and  parameter  settings 
available  to  them,  and  where  necessary  to  introduce  variations 
oriented  towards  their  own  requirements.  By  highlighting  some  of 
the  problems  and  dilemmas  facing  an  operating  system  designer,  it 
may  help  them  to  moderate  their  complaints  and  organize  their 
workload  to  improve  the  flexibility  and  performance  of  an 
existing  operating  system. 

The  book  will  be  of  interest  to  students  and  teachers  of  Computer 
Science,  because  many  of  the  problems  discussed  are  the  same  as 
those  facing  designers  of  any  large  program,  particularly  real¬ 
time  programs,  which  have  to  react  sensibly  to  peripheral 
equipment  and  human  users,  and  take  frequent  decisions  of  policy 
on  partial  evidence. 

[CR25,650  From  the  Preface  by  T.Hoare  and  R.  Perrott] 


■■■  Hoare,  C.A.R.,  and  Dahl,  O.-J.;  Notes  on  Data  Structuring;  In 
Structured  Programming,  Academic  Press  (1972)  pp. 83-174. 


■■■  Hoare,  C.A.R.,  and  McKeag,  R.M.;  A  Survey  of  Store  Management 
Techniques-Part  I;  in  Hoare  and  Perrott  (eds.).  Operating  Systems 
Techniques  (1972)  pp. 117-131. 

This  paper  is  a  descriptive  exploration  of  storage  management 
methods,  restricted  by  the  assumption  that  programs  must  be 
allocated  contiguous  space  in  the  physical  memory  for  proper 
operation.  Starting  with  a  raw  machine,  the  authors  describe  a 
series  of  increasingly  sophisticated  management  techniques, 
ultimately  arriving  at  a  multiprogramming  allocation  method  which 
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makes  use  of  fixed  length  pages  without  assuming  that  address 
mapping  hardware  for  true  paging  is  available.  The  development 
is  easily  read,  and  makes  the  case  for  multiprogramming  without 
fancy  hardware.  The  paper  is  worth  reading  for  its  historical 
content  alone,  since  it  describes  a  number  of  methods  which  have 
been  (or  are  currently  being)  used  to  achieve  efficient 
utilization  of  main  memory. 

The  reviewer  has  only  one  disagreement  with  the  presentation:  the 
authors  make  some  sweeping  statements  (e.g.,  the  resident  monitor 
is  usually  placed  in  the  high  order  part  of  the  memory)  which 
seem  unjustified.  If  one  ignores  these  pronouncements  and  treats 
them  as  concrete  examples  from  a  variety  of  possibilities,  then 
the  generalizations  are  excusable  on  the  basis  that  the 
algorithms  described  are  much  easier  to  understand. 

The  reader  looking  for  detailed  evaluation  and  analysis  of  the 
various  algorithms  will  have  to  look  elsewhere.  The  material  is 
qualitative  and  descriptive,  but  only  makes  passing  reference  to 
analytic  results.  [CR25,655  V.G.  Cerf] 


■■■  Hoare,  C.A.R.,  and  McKeag,  R.M.;  A  Survey  of  Store  Management 
Techniques-Part  II;  in  Hoare  and  Perr ott (eds. ) ,  Operating  Systems 
Techniques  (1972)  pp. 132-151. 

This  paper  is  the  sequel  to  part  I  (see  preceding  review),  and 
begins  with  a  description  of  the  implementation  of  paging  (with 
address  mapping  and  page  tables)  and  the  segmentation.  The 
latter  subject  is  mentioned  only  lightly,  with  the  bulk  of  the 
attention  going  to  the  problems  which  arise  in  the  implementation 
of  paging  systems  which  must  make  use  of  backing  store.  As 
before,  the  treatment  is  mainly  descriptive  and  qualitative. 
Reference  is  made  to  more  analytic  papers  in  the  bibliography. 

I  would  like  to  quibble  with  several  comments  made  with  regard  to 
program  sharing  in  a  paging  environment.  The  first  issue  is  the 
ease  with  which  sharing  of  subroutines  can  be  accomplished  in  a 
paging  system.  The  sharing  processes  must,  generally,  allocate 
the  same  portion  of  their  virtual  spaces  to  the  subroutine,  since 
it  has  presumably  been  compiled  (and  link  edited)  to  run  only  at 
a  specific  place  in  virtual  memory,  no  matter  how  many  processes 
are  using  it.  Then  every  process  which  makes  use  of  any 
subroutine  must  allocate  space  in  its  virtual  memory  for  the 
entire  library.  Sharing  of  text  file  pages  is  not  so  limited, 
since  any  process  can  associate  a  file  page  with  a  random  page  of 
virtual  memory  without  serious  penalty.  Furthermore,  it  is  not 
just  subroutines  which  might  be  shared.  Many  multiprogramming 
systems  increase  efficiency  by  sharing  the  same  copy  of  an  editor 
or  compiler  among  all  users,  taking  care  to  allocate  separate 
data  pages  for  each  user,  and  insuring  that  the  shared  program  is 
reentrant.  Such  sharing  is  considerably  easier,  at  least 
conceptually,  in  a  segmented  system,  since  each  user  can  assign 
different  segment  identifiers  to  the  same  program  without  penalty 
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(the  MULTICS  system  and  the  Burroughs  B6700  systems  are  good 
examples)  . 

Another  point  involves  the  cost  of  providing  a  large  virtual 
memory  for  the  user,  independent  of  the  physical  memory  actually 
available.  While  it  is  true  that  for  each  additional  page  of 
virtual  memory,  one  needs  only  one  more  entry  in  a  page  table,  it 
is  important  to  note  that  doubling  the  virtual  memory  size 
requires  the  addition  of  one  more  bit  in  the  address  field  of 
each  machine  word. 

On  the  whole,  readers  will  find  this  paper  easy  to  read.  The 
paper  would  be  a  suitable  basis  for  interesting  discussion  in  an 
undergraduate  class  on  operating  systems.  The  systems  designer 
may  leave  unsatisfied  to  the  extent  that  it  is  still  not  clear 
how  to  compare  quantitatively  the  many  algorithms  explored. 
( CR2 5, 656  V.G.  Cerf] 


■■■  Hoare,  C.A.R.;  Proof  of  Correctness  of  Data  Representations; 
Acta  Informatica  1,  S pringer-Verlag  (1972)  pp. 271-281 . 


■■■  Hoare,  C.A.R.;  Towards  a  Theory  of  Parallel  Programming;  in 
Hoare,  C.A.R.,  and  Perrott,  R.H.(eds.),  Operating  Systems 
Techniques,  Academic  Press,  N.Y.  (1972)  pp. 61-71. 

The  role  of  the  semaphore  in  insuring  the  correct  execution  of  a 
set  of  concurrent  processes  is  well  known,  theoretically 
sufficient,  but  somewhat  error-prone  when  used  in  actual 
programs,  and  being  rather  too  primitive  an  operation  to  use 
conveniently  in  proving  system  correctness.  In  the  same  sense 
that  sets  of  high-level  control  structures  have  been  proposed  to 
eliminate  the  conditional  branch  from  explicitly  occurring  in  a 
program,  the  author  proposes  in  this  paper  a  set  of  high-level 
control  structures  for  process  synchronization  which  effectively 
hide  the  semaphore  from  the  programmer’s  view. 

The  author  proceeds  by  noting  a  need  in  the  theory  of  parallel 
processes,  and  then  proposing  a  high-level  construct  to  answer 
that  need;  he  then  gives  an  example  of  the  use  of  this  construct. 
In  this  manner,  he  covers  a  method  of  specifying  that  processes 
be  executed  in  parallel,  a  method  of  specifying  critical  regions 
within  processes  with  respect  to  resources,  and  a  method  for 
conditional  execution  of  critical  regions  within  processes. 

The  paper  is  very  well  presented.  Anyone  with  an  interest  in 
operating  systems  or  programming  languages  could  benefit  from 
reading  this  exposition  of  the  language  problems  involved  in 
parallel  processes.  I  would  especially  recommend  it  to  students 
in  software  architecture,  software  engineering,  and  operating 
systems  courses.  [CR25,944  G.N.  Cederquist] 
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■■■  Hoare,  C.A.R.,  with  Clint,  M.  ;  Program  Proving:  Jumps  and 
Functions;  Acta  Informatica  1,3  (1972)  pp. 214-224, 


■■■  Hoare,  C.A.R.;  A  Note  on  the  FOR  Statement;  BIT  12,3  (1972) 
pp. 334-341 . 

This  short  but  thoughtful  paper  is  concerned  with  various 
restrictions  that  can  be  placed  on  the  f or-statement  and  the 
conseguences  of  these  restrictions.  In  the  most  restrictive 
form,  neither  the  variable  of  iteration,  the  upper  limit  of 
iteration,  nor  the  iteration  increment  can  be  modified  from 
within  the  loop;  furthermore,  no  transfers  are  permitted  from 
outside  the  loop  into  the  loop.  Applying  some  or  all  of  these 
restrictions  has  two  con  sequences:  it  allows  more  efficient 
implementation,  and  it  makes  proofs  concerning  the  for-loop  much 
simpler.  The  author  makes  the  point  that  these  two  consequences 
have  a  natural  connection  with  each  other.  He  further  argues 
that  most  for-loops  actually  do  satisfy  these  restrictions,  and 
that  programs  that  don*t  satisfy  them  ought  to  use  some  other 
construction.  This  paper  is  worthwhile  reading  for  both  language 
designers  and  those  concerned  with  program  verification. 
[ CR24 , 7 1 8  P.W.  Abrahams] 


■■■  Hoare,  C.A.R.;  Prospects  for  a  Better  Programming  Language; 
Infotech  State  of  the  Art  Lecture  Report  No. 7,  High  Level 
Languages  (1972)  pp. 327-343. 


mmm  Hoare,  C.A.P.,  with  Allison,  D.C.S.;  Incomputability; 
Computing  Surveys  4,3  (Sept.  1972),  169-178. 

Quite  often  in  Computing  Science  undergraduate  courses  it  is 
stressed  that  beside  their  importance  in  foundations, 
computability  results  are  useful  in  knowing  which  algorithms 
programmers  should  not  attempt  to  write.  Very  recently,  Robert 
Floyd  (in  R.E.  Miller  and  J. W.  Thatcher  Eds.,  Complexity  of 
Computer  Computations,  Plenum  Press,  New  York  1972;  CR  14,1  (Jan. 
1973),  Rev. 24, 436.)  remembers  that  about  ten  years  ago,  after  the 
publication  of  ALGOL  60  Report,  before  realizing  that  the  problem 
of  syntactic  ambiguities  was  unsolvable,  he  put  a  considerable 
effort  into  trying  to  design  algorithms  to  test  formal  languages 
for  ambiguities.  Computability  results,  hence,  have  a  practical 
interest  and  can  be  phrased  in  terms  that  can  be  understood  by 
programmers.  Despite  its  very  general  title  this  paper  goes  only 
a  very  little  step  in  this  direction  by  showing  in  terms  of  LISP 
and  ALGOL  programs  what  the  "Russell  paradox"  and  the  "Halting 
problem"  are  about,  and  under  what  conditions  subrecursive 
languages  and  typed  languages  can  avoid  inconsistencies. 

The  point  is  now  the  following:  is  it  more  convenient  to  restate 
theoretical  results  in  practical  terms,  or  is  it  better  to  give 
any  computer  scientist  enough  theoretical  background  to  know 
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which  are  the  recursion  theoretic  properties  of  the  objects  they 
are  dealing  with?  [CB25,241  G.  Ausiello] 


•  Hoare,  C.A.B.;  The  Quality  of  Software;  Software- Practice  and 
Experience  2  (1972)  pp. 103-105. 

The  main  problem  in  the  design  of  any  engineering  product  is  the 
reconciliation  of  a  large  number  of  strongly  competing 
objectives.  In  the  case  of  general-purpose  computer  software,  I 
have  made  a  list  of  no  less  than  seventeen:  1)  clear  definition 
of  purpose;  2)  simplicity  of  use;  3)  ruggedness;  4)  early 
availability;  5)  reliability;  6)  extensibility  and  improvabi lity 
in  light  of  experience;  7)  adaptability  and  easy  extension  to 
different  configurations;  8)  suitability  to  each  individual 
configuration  of  the  range;  9)  brevity;  10)  efficiency  (speed); 
11)  operating  ease;  12)  adaptability  to  wide  range  of 
applications;  13)  coherence  and  consistency  with  other  programs; 
14)  minimum  cost  to  develop;  15)  conformity  to  national  and 
international  standards;  16)  early  and  valid  sales  documentation; 
and  17)  clear,  accurate  and  precise  user's  documents. 

There  can  be  little  doubt  that  modern  software  fails  to  reconcile 
these  objectives,  particularly  with  respect  to  one  or  more  of 
(1)  —  (6),  (8)-(10),  (14)  and  (17).  What  is  the  solution?  The 
first  necessity  is  for  the  software  designer  and  his  customers  to 
recognize  that  there  is  a  conflict  of  objectives,  and  that  there 
is  the  need  for  compromise.  Secondly,  it  is  essential  that  the 
compromise  be  selected  in  the  light  of  a  sound  knowledge  of  good 
algorithms  and  program  structures,  and  not  merely  as  a  result  of 
wishful  thinking  of  a  sales  or  product  specification  department. 

...Unfortunately,  in  the  past  decade,  software  writers'  main 
pride  has  been  to  implement  an  arbitrary  specification  handed 
down  to  them  from  'above'  (e.g.,  ALGOL68,  PL/I);  and  not  to  pay 
much  concern  to  the  quality  of  either  the  specification  or  the 
product.  They  tend  to  argue  from  the  fact  that  you  can  do 
anything  by  software  to  the  conclusion  that  you  can  do  everything 
by  software.  And  you  can,  too;  but  is  it  worth  it?  Only  very 
few  software  designs  (a  notable  example  being  PASCAL)  have 
actually  been  made  to  optimize  the  quality  of  the  product  in  the 
light  of  known  software  techniques. 

So  my  advice  to  the  designers  and  implementors  of  software  of  the 
future  is  in  a  nutshell:  do  not  decide  exactly  what  you  are 
going  to  do  until  you  know  how  to  do  it;  and  do  not  decide  how  to 
do  it  until  you  have  evaluated  your  plan  against  all  the  desired 
criteria  of  quality.  And  if  you  cannot  do  that,  simplify  your 
design  until  you  can.  [CB23,801  From  the  Guest  Editorial] 


■■■  Hoare,  C.A.B.;  Parallel  Programming:  An  Axiomatic  Approach; 
Stanford  University,  Dept,  of  Computer  Science  (1973). 
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mmm  Hoare,  C.A.B.;  Hints  on  Programming  Language  Design;  ACM 
Symposium  on  the  Principles  of  Programming  Languages,  Boston 
(October  1973)  pp.1-30. 


■■■  Hoare,  C.A.E.;  A  Structured  Paging  System;  Computer  J.  16,3 
(August  1973)  pp. 209-215. 

According  of  the  author,  "this  paper  attempts  to  extend 
structured  programming  methods  to  a  program  intended  to  operate 
in  a  parallel  environment,  namely  a  paging  system  for  the 
implementation  of  virtual  store."  The  structured  programming 
style  employed  leans  heavily  on  notations  drawn  from  Pascal  and 
SIMULA  67  enriched  with  some  synchronization  concepts  of 
Dijkstra.  Nothing  new  is  claimed  of  the  algorithm  itself,  the 
author  has  merely  (?)  attempted  to  give  known  techniques  a 
complete,  concise,  and  intelligible  abstract  definition.  In 
short,  he  has  tried  to  program  the  algorithm  in  such  a  way  that 
both  its  correctness  and  general  applicability  to  various 
hardware  characteristics  and  workloads  will  be  easy  to  examine. 
In  my  view,  he  has  succeeded  admirably. 

Structured  multiprogramming  is  achieved  by  the  explicit  use  of 
monitors  and  condition  variables.  A  monitor  is  a  primitive 
program  object  "consisting  of  one  or  more  items  of  data,  together 
with  one  or  more  procedures  operating  in  that  data...  with  the 
additional  understanding  that  the  bodies  of  the  procedures  local 
to  the  object  will  not  be  executed  in  parallel,  or  interleaved 
with  each  other."  Calls  on  monitor  procedures  are  made  by 
qualifying  the  procedure  name  with  that  of  the  monitor:  "a.b" 
invokes  procedure  b  of  monitor  a.  The  only  operations  defined 
for  condition  variables  are  those  of  "waiting"  and  "signaling." 
"Signaling"  a  condition  terminates  only  the  wait  of  the  longest 
waiting  process.  Within  a  monitor,  when  a  wait  ends  as  a  result 
of  a  signal,  the  waiting  process  resumes  immediately  in  place  of 
the  signaling  program,  and  the  signaling  program  resumes  only 
when  the  previously  waiting  program  releases  exclusion  again. 

Using  these  two  notions,  concise  procedures  are  described  for 
managing  a  paging  system  consisting  of  a  main-store,  drum-store, 
and  virtual-store.  Main-store  consists  of  a  given  number  of 
main-page-frames,  each  of  which  has  a  delay  condition  and  a 
lockout  flag.  Each  virtual  page  has  a  local  variable  indicating 
whether  or  not  it  occupies  a  main  or  a  drum-page  frame  or  is 
"clear,"  a  variable  giving  the  physical  location  in  main  or 
drumstore,  a  "usebit"  indicating  that  the  page  is  being 
referenced,  and  an  "unchanged"  bit  indicating  that  the  main  and 
drum  copies  are  identical.  The  SIMULA  67  notion  of  class  is 
extended  so  that  a  single  monitor  can  apply  separately  to  each 
virtual  page  to  provide  the  operations  (monitor  procedures) : 
bring-in,  throw-out,  automatic  discard,  clear,  fetch  the  contents 
of  a  word,  assign  the  contents  of  a  word,  lock,  unlock,  discard 
now,  and  discard  soon. 
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The  paper  provides  a  would-be  paging  system  dsigner  with  an 
excellent  conceptual  framework  around  which  to  organize  an  actual 
implementation,  however,  as  the  author  points  out  "the  quality  of 
the  final  product  will  depend  critically  on  the  skill  and 
ingenuity  of  the  implementor."  The  author  does  not  include  a 
correctness  proof  or  any  quantitative  investigation  of 
performance.  [CR26,531  A.F.  Ackerman] 


■■■  Hoare,  C.A.R.,  and  Wirth,  N.;  An  Axiomatic  Definition  of  the 
Programming  Language  PASCAL;  Acta  Informatica  2  (1973)  pp. 335- 
355. 


■■■  Hoare,  C.A.R. ;  Recursive  Data  Structures;  Stanford 
University,  Computer  Science  Dept.,  STAN-CS-73-400  (October  1973) 
pp. 1-32. 

The  power  and  convenience  of  a  programming  language  may  be 
enhanced  for  certain  applications  by  permitting  tree-like  data 
structures  to  be  defined  by  recursion.  This  paper  suggests  a 
pleasing  notation  by  which  such  structures  can  be  declared 
processed;  it  gives  the  axioms  which  specify  their  properties, 
and  suggests  an  efficient  implementation  method.  It  shows  how  a 
recursive  data  structure  may  be  used  to  represent  another  data 
type,  for  example,  a  set.  It  then  discusses  two  ways  in  which 
significant  gains  in  efficiency  can  be  made  by  selective  updating 
of  structures,  and  gives  the  relevant  proof  rules  and  hints  for 
implementation.  The  examples  show  that  a  certain  range  of 
applications  in  symbol  manipulation  can  be  efficiently  programmed 
without  introducing  the  low-level  concept  of  a  reference  into  a 
high-level  programming  language. 

From  the  Author  Abstract. 

It  appears  to  this  reviewer  that  over  the  next  few  years  there 
will  begin  to  appear  new  programming  languages  in  which  the 
description  of  algorithms  will  take  second  place  to  the 
description  of  data  structures,  and  that  this  is  indeed  a 
desirable  direction  in  which  to  migrate.  We  seem  to  have  some 
properties  of  control  structures  well  in  hand,  due  to  the 
developments  of  Dijkstra,  Mills,  et  al. ;  in  this  paper  the  author 
points  out  similarities  in  the  realm  of  data  structures,  and 
shows  that  the  same  general  tools  used  in  describing  (recursive) 
control  structures  are  applicable  to  the  description  of  data 
structures  in  recursive  fashion. 

The  paper  is  well  worth  reading,  and  strongly  recommended  to 
language/compiler  designers  and  implementers. 

[ CR29 , 16  5  L.D.  Yarbrough] 


Hoare,  C.A.R.;  Monitors:  An  Operating  System  Structuring 
Concept;  CACM  17,10  (October  1974)  pp. 549-557. 
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■■■  Hoare,  C.A.R.,  and  Lauer,  P.E.;  Consistent  and  Complementary 
Formal  Theories  of  the  Semantics  of  Programming  Languages;  Acta 
Informatica  3,2  (1974)  pp. 135-153. 

This  is  a  valuable  paper  which  compares  formal  methods  of 
defining  the  semantics  of  programming  languages  by  applying  four 
methods  to  a  simple  language.  The  four  methods  range  from  the 
constructive  approach  utilizing  an  abstract  machine  for 
describing  program  execution,  to  the  abstract  approach  of 
defining  the  language  by  axioms  and  rules  of  inference  which  form 
the  basis  for  correctness  proofs.  The  more  abstract  methods  are 
proven  to  be  consistent  relative  to  the  more  concrete  ones,  and  a 
brief  discussion  of  extending  the  language  and  the  corresponding 
definitions  is  given.  Some  other  methods  of  semantic  definition 
are  also  summarized  but  again,  only  briefly.  The  authors 
conclude  by  recommending  that  programming  languages  be  defined  by 
different  methods  oriented  to  the  needs  of  different  people 
concerned  with  the  language;  for  example,  constructive  methods 
for  implementors,  and  abstract  methods  for  users.  They  further 
recommend  that  such  definitions  be  related  by  proofs  of 
consistency.  All  in  all,  these  seem  like  very  sensible 
recommendations. 

Unfortunately,  the  paper  contains  several  annoying  typographical 
errors,  the  worst  of  which  is  contained  in  the  rule  of  inference 
D3  on  page  146  which  should  be: 

(P5b)  {Q}P 
D3 .  _ _ 

P{b*Q)  (-bSP)" 

The  brief  treatment  of  extensions  and  secondary  semantic 
definitional  methods  is  also  disappointing,  but  the  merits  of  the 
paper  far  outweigh  these  deficiencies.  [CR27, 633  J.M.  Adams] 


Hoare,  C.A.R.;  Data  Reliability;  International  Conference  on 
Reliable  Software,  SIGPLAN  Notices  10,6  (June  1975)  pp. 528-533. 


Hoare,  C.A.R.;  Program  Correctness  Proofs;  Formal  Aspects  of 
Computing  Science,  Newcastle  upon  Tyne,  3-6  Sept.  1974  (1975) 
pp.7-45 . 


■■■  Hoare,  C.A.R.,  with  Enslow,  P.H.,  Palme,  J.,  Parnas,  D.L., 
and  Pyle,  I.;  Implementation  Languages  for  Real-Time  Systems,  I. 
Standardisation-Its  Implementation  and  Acceptance;  Report  ER0-2- 
75-Vol-1;  II.  Language  Design-General  Comments;  Report  ERO-2-75- 
Vol02 ;  III.  Command  and  Control  Languages-Specif ic  Comments; 
Report  ERO-2-75-Vol-3 ,  European  Res.  Office  London  (15  April 
1975)  . 
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■■■  Horning,  J.J. ,  and  Randell,  B. ;  Process  Structuring; 
Computing  Surveys  5  (1973)  pp.5-30. 


■■■  Horning,  J.J.;  What  the  Compiler  Should  Tell  the  User;  in 
Bauer,  F.  L.  and  Eickel,  J.  (eds. )  Compiler  Construction,  An 
Advanced  Course,  Springer-Verlag  (1974)  525-548. 


■■■  Horning,  J.J.,  Lauer,  H.C.,  Melliar-Smith ,  P. H. ,  and  Randell, 
B.;  A  Program  Structure  for  Error  Detection  and  Recovery;  in 
Gelenbe,  E.  and  Kaiser,  C.  (eds.).  Operating  Systems,  Proceedings 
of  An  International  Symposium,  Springer-Verlag  Rocenquencourt 
(1974)  pp. 171-178. 

The  paper  describes  a  method  of  structuring  programs  which  aids 
the  design  and  validation  of  facilities  for  the  detection  of  and 
recovery  from  software  errors.  Associated  with  the  method  is  a 
mechanism  for  automatic  preservation  of  restart  information  at  a 
level  of  overhead  which  is  believed  to  be  tolerable. 

From  the  Author  Abstract. 

The  recovery  scheme  is  only  in  the  early  stages  of  development, 
and  its  value  has  yet  to  be  demonstrated,  but  brief  experiments 
inter pretivel y  executing  ALGOL  W  are  enouraging.  The  paper  is 
preliminary  status  report  on  a  promising  technique,  which  is  only 
one  aspect  of  a  project  at  the  University  of  Newcastle  upon  Tyne 
to  investigate  computer  system  reliability, 
f  CR28, 268  T.R.  Baley] 


■■■  Horning,  J.J.,  with  Gannon,  J.D.;  The  Impact  of  Language 
Design  on  Program  Reliability;  International  Conference  on 
Reliable  Software,  Los  Angeles  (April  1975)  pp. 10-22. 


■■■  Horning,  J.J.,  with  Gannon,  J.D.;  Language  Design  for 
Programming  Reliability;  IEEE  Transactions  on  Software 
Engineering  1,2  (1975)  pp. 179-191. 


This  well-written  and  readable  paper  presents  a  survey  of 
sensible  views  about  the  relationship  between  programming 
language  design  and  program  reliability,  and  supports  these  views 
with  a  wide-ranging  bibliography.  The  main  part  of  the  paper 
reports  a  well-conducted  experiment  comparing  the  performance  of 
two  groups  of  students  in  an  operating  systems  course  using  two 
specially  designed  versions  of  a  teaching  language.  The  versions 
differed  mainly  in  syntactic  detail,  but  one  version  permitted 
more  compile-time  checks  against  semantic  errors.  The  most 
significant  results  of  the  experiment  confirmed  the  common  sense 
belief  that  errors  detected  at  compile  time  are  removed  more 
guickly,  and  the  student  learns  faster  not  to  make  them,  even 
though  the  crude  number  of  errors  may  be  higher  at  the  beginning. 
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The  paper  is  also  quite  frank  about  the  dangers  and  dificulties 
of  such  studies;  that  they  depend  on  the  student’s  previous 
conditioning,  and  on  small  samples  from  a  highly  nonhomogeneous 
population,  highly  subject  to  disturbance  by  extraneous  factors. 
Further  dangers  are  the  extrapolation  of  results  from  students  to 
more  experienced,  or  even  professional  programmers,  and  the  use 
of  results  derived  from  extremely  high  error  rates  to  situations 
in  which  (one  hopes)  error  rates  are  very  close  to  zero. 

The  authors  conclude  that  there  remains  much  to  be  done  in  the 
design  of  languages  for  reliable  software,  and  in  the 
experimental  evaluation  of  language  design  decisions, 
particularly  to  discover  the  effects  of  different  environments. 
But  it  is  important  to  remember  that  experiments  must  be  designed 
to  test  hypotheses  and  theories  of  language;  and  it  is  the 
theories  that  should  dictate  the  design  principles  and  the 
details  of  a  programming  language.  An  attempt  to  design  a 
language  by  mere  experimentation  would  be  futile  and  ridiculous. 
The  authors'  eminently  sensible  theories  have  been  supported  by 
their  experiments,  and  future  experiment ors  can  safely  use  their 
project  as  a  model.  [CR29,414  C.A.R.  Hoare] 


■  ■■  Horning,  J. J.  ;  Yes!  High  Level  Languages  Should  be  Used  to 
Write  System  Software;  ACM'75  Proc. ,  Minneapolis  (1975)  pp. 206- 
208. 


■■■  Horning,  J.J.;  The  Software  Project  as  a  Serious  Game;  in 
Wasserman,  A. I.  (ed.).  Software  Engineering  Education:  Needs  and 
Objectives,  Springer-Verlag  (1976). 


■■■  Horning,  J.J.;  Some  Desirable  Properties  of  Data  Abstraction 
Facilities;  Proc.  of  the  Conference  on  Data:  abstraction, 
definition  and  structure.  Salt  Lake  City  (March  1976)  SIGPLAN 
Notices  (March  1976)  pp. 60-62. 


■■■  Horning,  J.J.,  and  Wortman,  D.B.;  Software  Hut:  A  Computer 
Program  Engineering  Project  in  the  Form  of  a  Game;  IEEE 
Transactions  on  Software  Engineering  (July  1977). 


■  ■■  Jackson,  M.A.;  Improving  Programming  Techniques;  Infotech 
S tate-of-the- Art  Report  No. 8,  (1972)  pp. 273-293. 


■  ■■  Jackson,  M.  A.  ;  The  Future  of  Programming;  Infotech  State-of- 
the-Art  Report,  Commercial  Language  Systems  (1974)  pp, 337-352. 


■  Jackson,  M.A.;  Principles  of  Program  Design;  Academic  Press, 
1  975. 
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■■■  Jackson,  M.A.;  Constructive  Methods  of  Program  Design;  Proc. 
ECI  Conference,  Springer-Verlag  Notes  on  Computer  Science  No. 44 
(1976)  . 


■■■  Jackson,  M.A.;  COBOL;  Proceedings  of  BCS  Software  Engineering 
Symposium  (1976). 


mmm  Jones,  C.B.,  with  Henhapl,  W.;  The  Block  Concept  and  Some 
Possible  Implementations,  with  Proofs  of  Equivalence;  IBM, 
Vienna,  TR25.  104  (April  1970). 


■■■  Jones,  C.B.,  with  Henhapl,  W. ;  A  Run-time  Mechanism  for 
Referencing  Variables;  Information  Processing  Letters  1,1  (1971). 


■  Jones,  C.B.,  and  Lucas,  P.;  Proving  Correctness  of 
Implementation  Techniques;  in  Engler,  E.(ed.),  A  Symposium  on 
Algorithmic  Languages,  Lecture  Notes  in  Mathematics  No. 188, 
Springer-Verlag  (1971). 


■■■  Jones,  C.B.;  Formal  Development  of  Correct  Algorithms;  an 
Example  Based  on  Early's  Recognizer,  ACM  Conference,  SIGPLAN 
Notices  7,1  (January  1972). 


■■■  Jones,  C.B.,  with  Allen,  C.D.;  The  Formal  Development  of  An 
Algorithm;  IBM,  Hursley  TR-12.110  (March  1973). 


■■■  Jones,  C. B. ;  Formal  Development  of  Programs;  IBM,  Hursley 
TR 1 2.  117  (June  1973)  . 

■■a  Jones,C.B.,  with  Hanford,  K.V.;  Dynamic  syntax:  a  concept  for 
the  definition  of  the  syntax  of  programming  languages;  in  Annual 
review  in  automatic  programming,  Vol.7,  Part  2,  1973,  115-142. 
See  main  entry  CR29,401. 

This  informal  paper  concerns  a  mechanism  for  coping  with  the 
noncontext-free  properties  of  the  syntax  of  high-level 
programming  languages  such  as  ALGOL-60.  Some  of  the  problems 
involved  are;  matching  the  declaration  to  the  use  of 
identifiers;  array  dimensions  or  procedure  parameters;  and  the 
scope  rules  of  block  structure.  A  method  is  called  "dynamic 
syntax"  is  used.  This  consists  of  augmenting  the  set  of 
productions  of  the  grammar  for  the  language  with  other 
productions  which  describe  such  features  of  a  program  as  the  set 
of  identifiers,  or  the  number  of  dimensions  of  an  array.  A 
variant  of  the  lambda  calculus  is  used  to  manipulate  the  set  of 
productions.  In  effect,  the  paper  constructs  a  lambda  calculus 
recognizer  for  a  sizable  subset  of  ALGOL-60,  based  on  its  BNF 
description. 
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Since  the  original  work  on  the  topic  was  done  in  1966,  the 
authors  don't  mention  more  recent  developments  on  this  problem, 
such  as  Aho's  indexed  languages  ["Indexed  grammars--an  extension 
of  context-free  grammars,"  J. ACM  15,4  (Oct.  1 968) ,647-671 ;  CR10,5 
(May  1969),  Rev. 16,745],  and  Peter  Wegner's  "Vienna  Definition 
Language"  Computing  Surveys  4,1  (March  1972)5-63;  CR13,10  (Oct. 

1  972)  , Rev. 23, 937.  [CR29,459  R.  Moenck  ] 


■■■  Jones,  C.B.,  with  Bekic,  H.,  Bjorner,  D.,  Henhapl,  W.,  and 
Lucas,  P.;  Formal  Definition  of  a  PL/I  Subset;  IBM,  Vienna 
TR25.139  (December  1974). 


■  ■■  Jones,  C.B.;  Formal  Definition  in  Program  Development;  in 
Programming  Methodology,  Lecture  Notes  in  Computer  Science  No. 23 
(1975)  . 


■■■  Jones,  C.B.;  Formal  Definition  in  Compiler  Development;  IBM, 
Vienna  TR25.145  (February  1976). 


■■■  Jones,  C.B.;  Some  Requirements  of  Specification  Languages; 
IBM,  Vienna  LN25.3.108  (February  1976). 


■■■  Lavrov,  S.S.;  Conference  on  Algorithmic  Languages  and  Their 
Application  for  the  Construction  of  Models;  Vestnik  Akademii  Nauk 
SSSR  37,12  (1967),  78-80. 

This  is  an  account  of  the  conference  held  in  Oslo,  May  22-26, 
1967,  and  devoted  to  papers  on:  1)  the  theory,  principles,  and 
methods  of  model  construction;  2)  algorithmic  languages  for  the 
description  of  the  process  of  model  construction; 
3)  organizational  problems  in  the  amassing  and  treatment  of 
information  in  the  course  of  model  construction;  4)  structure  of 
treated  data;  5)  problems  in  raising  the  effectiveness  and 
reliability  of  systems  of  model  construction;  and  6)  typical 
models  of  complex  systems.  [CR17,111  I.D.  London] 
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■■■  Lavrov,  S.S.;  On  Problem  Solving  on  a  Computer  and  Proving 
Program  Correctness;  Probl.  Prokl.  Mat.i  Mekh,  Nauk  (Publ.)  USSR 
(1971)  pp. 98-102  (Russian). 

The  author  considers  the  questions  of  necessity  and  possibility 
of  proving  program  correctness  in  problem-solving  on  computers. 
It  is  shown  that  a  formal  proof  of  program  correctness  is 
possible  in  comparatively  rare  cases.  The  author  points  out  the 
desirability  of  combining  formal  proofs  with  more  traditional 
methods  of  verifying  program  correctness. 

[CR23,843  Courtesy  Ref.Zh.] 


Author  Abstract 
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■■■  Lavrovr  S.S. ;  Language  Foundations  of  Computer  Applications; 
Zh.  Vychisl.  Mat.i  Mat.Fiz  11,2  (1971)  pp. 498-504  (Russian). 

The  author  considers  differences  between  programming  languages 
and  traditional  mathematical  symbolism.  He  mentions  some 
peculiarities  of  programming  language  developments  and 
applications,  and  presents  some  principle  features  of  a  new 
approach  toward  constructing  a  universal  programming  language 
[CR23,202  Courtesy  Ref.Zh.] 

Author’s  Abstract 


Lehman,  M.M.,  with  Belady,  L.A.;  Programming  System  Growth 
Dynamics;  or  the  Meta-Dynamics  of  Systems  in  Maintenance  and 
Growth;  IBM  Research  Center,  Yorktown  Heights,  no.RC3456 
(September  1971). 


■  ■■  Lehman,  M.M. ,  with  Belady,  L.A.;  An  Introduction  to  Growth 
Dynamics;  in  Freiberger,  W.(ed.),  Statistical  Computer 
Performance,  Academic  (1972). 

A  macro-model  for  the  effort  (men,  machine-power,  cost,  etc.) 
required  to  take  a  large  programming  system  through  successive 
releases  is  discussed.  Although  it  appears  that  raw  data  can  be 
smoothed  or  averaged  to  fit  their  model  well,  the  authors  are 
unable  to  assign  numerical  values  to  the  model  parameters  or  to 
exhaustively  validate  the  model.  They  postulate  (analogous  to 
the  second  law  of  thermodynamics)  that  "the  complexity  or 
unstructuredness--the  entropy — of  a  programming  system  increases 
with  time  unless  more  effort  specifically  directed  to  its 
reduction  is  executed. 

Their  micro-model  [  "Programming  systems  growth  dynamics,"  IBM 
Research  Division  F.C3546,  Sept.  1971]  is  also  briefly  mentioned 
and  said  to  conform  to  such  heuristic  observations  as:  "good" 
programs  are  structured  [O.-J.  Dahl,  E. W.  Dijkstra,  and  C. A.R. 
Hoare,  Structured  Programming.  Academic  Press,  London,  1972; 
review  pending],  avoid  goto  statements,  and  share  parameters 
through  defined  programming-element  interfaces  rather  than 
through  global  variables. 

Readers  interested  in  quantitative  models  for  the  decay  of 
programs  will  find  this  paper  worthwhile,  especially  if  they 
ignore  the  poorly  labeled  graphs.  [CR24,599  J.  Alanen] 


■■■  Lehman,  M.M. ;  Computer  Usage  Control;  Computer  J.  16,2  (May 
1973)  pp. 106-110. 

This  paper  describes  the  design  objectives  and  goals  of  CASCOM,  a 
system  for  administrating  and  controling  the  computing  hardware 
resources  (360/91,  two  360/67* s,  and  others)  at  IBM  Research 
Labs.,  Yorktown  Hts. ,  N.Y.  The  basic  problem  to  which  CASCOM  is 
addressed  is  the  allocation  of  computing  resources  within  an 


36 


organization.  There  are  no  new  ideas  or  basic  concepts 
introduced,  but  the  material  is  concise  and  readable. 
Unfortunately,  the  paper  does  not  include  any  indication  of 
operational  experience  with  CASCOM,  although  an  original  version 
(APL/360  was  installed  in  late  1970  and  the  current  version 
(PL/I)  in  early  1972.  The  paper  will  be  of  interest  to  those 
with  computing  budget  responsibilities  or  computer  center 
management.  [CE26,049  G.K.  Hutchinson] 


■■■  Lehman,  M.M.;  Programs,  Cities,  Students-Limits  to  Growth?; 
in  Imperial  College  of  Science  and  Technology  Inaugural  .  Lecture 
Series,  London,  Vol.9,  (1970-1974)  pp. 211-229. 


■  ■■  Mcllroy,  M. D.  ,  and  Boon,  C. ;  The  Outlook  for  Software 
Components;  Infotech  State-of-t he-Art  Report  No. 11,  Software 
Engineering  (1972)  pp. 243-252. 


■■■  Mealy,  G.H.;  The  System  Design  Cycle;  in  Second  Symposium  on 
Operating  Systems  Principles,  Princeton,  October  1969  (1969) 
pp. 1-7. 


The  author  states: 

Technical  competence  in  system  design  encompasses  at  least  an 
appreciation  of  a  number  of  issues  that  are  often  dismissed  as 
being  merely  managerial  in  nature,  since  most  system  programmers 
seek  a  purely  technical  definition  cf  what  constitutes  a  system 
design,  if  they  think  about  the  problem  at  all.  This  paper 
reviews  the  area  between  the  purely  technical  and  the  purely 
managerial  as  it  pertains  to  the  design  portion  of  the  system 
development  cycle  and  finds  this  area  nonempty. 

The  paper  will  be  of  great  interest  for  programmers  as  well  as 
programming  managers  as  the  author  points  out  that  programming 
can  be  managed  and  that  management  techniques  successfully  used 
in  other  branches  of  engineering  are  not  inapplicable. 
[CR19,621  Y.  Muraoka] 


■■■  Naur,  P. ;  Programming  by  Action  Clusters;  BIT  9  (1969) 
pp. 250-258 . 

The  paper  describes  a  programming  discipline  that  aims  at  the 
construction  of  programs  by  converting  given  global  requirements 
into  sets  of  action  clusters  (sequences  of  algorithmic 
statements)  which  guarantee  that  the  requirements  are  always  met. 
These  clusters  are  then  used  as  building  blocks  to  construct  the 
final  program. 

The  author  illustrates  his  principle  of  action  clusters  by 
constructing  a  program  to  solve  a  text-editing  problem. 
Regrettably,  the  application  of  this  technique  to  the  given 
example  must  be  judged  a  failure,  as  it  has  the  following  bug: 
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the  program  produces  a  gratuitous  BLANK  as  the  first  output 
character,  where  none  appears  in  the  corresponding  position  of 
input  text.  [CR19,420  B.  Leavenworth] 


■■■  Naur,  P.  and  Randell,  B.  (eds.);  Software  Engineering;  NATO 
Scientific  Affairs  Division,  Brussels,  Belgium  (January  1969)  . 


■■■  Naur,  P. ;  The  Design  of  Large  Data  Systems;  Infotech  State- 
of-the-Art  Report  No. 11,  Software  Engineering  (June  1971)  pp.  447- 
459. 


■■■  Naur,  P. ;  An  Experiment  in  Program  Development;  BIT  12,3 
(1972)  pp. 347-365. 

This  article  is  fascinating  reading  for  anyone  interested  in  how 
programs  actually  get  written.  In  an  earlier  article  on 
programming  methodology  Wirth  presents  the  8-queens  problem,  and 
shows  how  a  program  to  solve  it  may  be  developed  by  "stepwise 
refinement".  The  present  paper  "was  initiated  by  the 
suggestion. .. by  Wirth  that  'the  reader  is  strongly  urged  to  try 
to  find  a  solution  by  himself  before  embarking  on  the  paper...' 
Looking  at  the  formulation  of  the  problem. .. and  finding  that  is 
was  not  one  which  I  had  done  before,  I  decided  to  follow  this 
suggestion,  and  to  make  the  solution  a  demonstration  of  the  way 
in  which  I  would  attack  the  problem,  before  reading  the  rest  of 
the  paper.  For  the  purpose  of  demonstration,  I  decided  to 
record,  as  far  as  possible,  my  complete  train  of  thought  as  typed 
note  s. " 

What  follows  is  a  complete  journal  of  program  development:  false 
starts,  blind  alleys,  bugs,  and  all.  Whereas  in  Wirth' s  paper 
the  program  seems  to  develop  inexorably  towards  a  f ore- orda ined 
final  form,  in  the  present  paper  the  human  element  of  the 
exploration,  educated  guesses,  and  rejected  alternatives  is 
always  present.  The  author  is  clearly  an  extraordinarily  careful 
programmer,  and  he  made  remarkably  few  errors  in  the  development 
of  the  program.  Yet  their  documentation  gives  this  paper  a 
realism  that  most  worked  examples  lack. 

The  author  invites  comparison  between  his  methodology  of  "action 
clusters"  and  the  "stepwise  refinement"  presented  in  [Wirth],  on 
the  basis  of  the  two  solutions  to  the  8-queens  problem.  The 
comparison  is  not  exact,  since  the  author  expends  considerable 
effort  in  eliminating  symmetries,  and  Wirth  does  not  eliminate 
them.  However,  symmetry  elimination  can  easily  be  added  to 
Wirth 's  program  for  purposes  of  comparison.  By  any  reasonable 
measure,  Wirth's  program  is  the  simpler  of  the  two,  and  its 
workings  are  more  easily  explained.  I  also  found  it  easier  to 
convince  myself  of  its  correctness. 

"Efficiency"  comparisons  are  more  difficult.  Both  programs  rely 
on  special  properties  of  solutions  (e.g.,  precisely  one  queen  in 
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each  row) ,  the  author’s  somewhat  more  than  Wirth's.  A  program 
that  merely  printed  out  the  twelve  distinct  solutions  might  be 
considered  more  "efficient"  than  either.  However,  the  author’s 
does  seem  to  have  a  slight  edge. 

The  article  concludes  with  the  pertinent  remark  that  it  is 
difficult  to  avoid  the  impression  that  program  development  styles 
have  to  allow  for  personality  factors.  [CR25,213  J.J.  Horning] 


■■■  Naur,P.;  Concise  survey  of  computer  methods. 
Studentlitterature ,  Lund,  Sweden,  1974,  397  pp. 

The  main  objection  to  this  book  is  directed  to  its  claim  to  be  a 
textbook.  In  the  preface  the  author  modestly  and  correctly 
state  s , 

The  depth  of  the  treatment  is  that  of  a  survey.  Certain 
methods  are  described  in  detail.  Many  more  are  merely 
mentioned  briefly.  Most  descriptions  are  given  in  a  simple, 
mostly  non-mathematical,  language.  The  basically  simple- 
minded  treatment  has  been  supplemented  with  an  extensive 
bibliography  of  suggestions  for  further  reading. 

Indeed,  if  a  student  were  to  follow  the  suggestion  of  the  author 
and  read  the  material  in  the  extensive  bibliography  (over  70 
pages,  or  nearly  20%  of  the  entire  text) ,  he  would  learn  a  lot, 
but  that  would  be  an  indirect  contribution  of  this  book.  After 
the  quoted  statement  about  the  scope  of  the  book,  the  author  (in 
the  same  preface)  prescibes  it  as  "suitable  for  self-study,  as 
well  as  for  class  work  at  the  early  to  intermediate  level  at 
universities,  schools  of  technology,  business  schools,  teachers' 
colleges,  and  similar  schools  of  intermediate  and  higher  levels 
of  education."  Referring  to  the  ACM  Curriculum  68,  the  author 
state  s, 

...the  present  text  may  be  used  following  the  basic  course, 
B 1 ,  Introduction  to  Computing.  The  text  provides  much  of  the 
material  included  in  course  II,  DataStructures,  and  some  of 
the  material  included  in  each  of  the  courses  12,  Programming 
Languages,  14,  Systems  Programming,  and  15,  Compiler 
Constuction. 

And  in  the  next  paragraph. 

As  related  to  "Curriculum  Recommendations  for  Graduate 
Professionals  in  information  systems  ["A  Report  of  the  ACM 
Curriculum  Committee  on  Computer  Education  for  Management,"  Comm. 
ACM  15,  (May  1972),  363-398;  CR  1  3,  10  (Oct..  1  972)  ,  Rev. 23, 869  the 
present  text  provides  a  fairly  complete  coverage  of  course  Cl, 
Information  Structures. 

All  this  material  is  indeed  covered,  but  only  to  the  extent  of 
being  "merely  mentioned"!  In  short,  there  is  nothing  in  this 
book  which  is  not  covered  in  much  more  detail,  and  with  more 
insight,  by  any  good  textbook  for  an  introductory  course  in 
computer  science.  However,  if  we  disregard  the  proposal  for  the 
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textbook,  all  the  exercises  in  the  book  notwithstanding,  then  it 
can  be  regarded  as  an  interesting  survey  or  an  outline  text  at  an 
elementary  level. 

The  18  chapters  of  the  book  are  divided  into  six  parts  touching 
upon  basic  definitions,  programming  languages,  data  elements, 
data  aggregates  and  structures,  man/machine  interaction,  file 
structure  and  data  sets,  large  data  systems,  storage  and  search 
technigues,  and  other  related  topics;  all  from  the  view  point  of 
"datalogy  and  datamatics" ,  as  the  author  puts  it.  Each  chapter 
is  provided  with  a  brief  summary  and  a  set  of  exercises  and 
problems.  The  original  text  was  written  in  Danish.  This  book  is 
a  much  shorter  English  version.  [CB28,043  J.A.Mone] 


Naur,  P. ;  Programming  Languages,  Natural  Languages,  and 
Mathematics;  CACM  18,12  (December  1975)  pp. 676-683. 


■  ■■  Parnas,  D.L. ;  On  the  Use  of  Transition  Diagrams  in  the  Design 
of  a  User  Interface  for  an  Interactive  Computing  System;  Proc. 
ACM  National  Conference  (1969)  pp.378-385. 

The  purpose  of  this  paper  is  to  present  and  support  the  position 
that  command  languages  (the  user  interface  with  terminal-oriented 
systems)  should  be  constructed  in  such  a  manner  as  to  simplify 
the  interaction  between  man  and  machine,  and  to  suggest  a 
technique  to  facilitate  such  implementation.  Languages  or 
procedures  of  this  type  should  be  user-oriented  and  avoid  such 
pitfalls  as: 

the  use  of  different  or  conflicting  formats  and  conventions 
from  command  to  command; 

the  creation  of  situations  or  loops  in  the  conventional  flow 
that  cannot  be  exited  from  e.g.,  the  system  continues  to 
interrogate  the  user  for  data  which  he  no  longer  can  enter; 
the  lack  of  provision  of  flexible  editing  facilities  that 
allow  correction  of  input  without  extensive  conversation  and 
reentry. 

A  terminal  state  is  defined  as  a  point  in  time  when  the  system  is 
ready  to  accept  input  messages  from  the  user.  A  terminal  state 
diagram  is  defined  as  a  flowchart-like  display  showing  each 
system-recognizable  entry  and  its  results  for  a  given  terminal 
state.  The  results  consist  of  the  reply  by  the  system  and  the 
next  terminal  state  reached.  Examples  of  terminal  states  and 
terminal  state  diagrams  are  provided. 

The  author  then  submits  the  view  that  the  use  of  terminal  state 
diagrams  in  the  early  design  stages  of  a  terminal-oriented  system 
would  result  in  the  elimination  of  most  of  the  examples  of  poor 
design  mentioned  earlier.  This  is  the  only  point  of  debate  that 
can  be  taken  with  this  article,  and  it  is  a  minor  one.  The 
desire  to  design  a  user-oriented  interactive  system  is  a 
management  decision  and  cannot  really  be  made  by  implementation 
teams.  Most  systems  are  sold  with  computing  hardware  or  as 
separate  packages  by  profit-making  organizations  to  data 
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processing  managers.  Most  da ta-processing  managers  are 
interested  in  keeping  computer-hardware-related  costs  down  and 
care  little  about  the  efficiency  of  user  personnel.  Only  when  it 
is  proven  and  accepted  that  optimization  of  the  programmer's  time 
and  effort  is  desirable  will  there  be  a  great  impetus  toward 
widespread  adoption  of  user-oriented  systems. 

Programmers,  however,  "know"  that  properly  designed  terminal- 
oriented  systems  are  desirable.  Therefore,  one  cannot  take  issue 
with  the  thesis  that  the  user-interface  should  be  designed  first, 
and  that  the  terminal  state  diagram  is  an  excellent  tool  for  both 
the  designer  and  the  user. 

This  paper  gives  an  excellent  introduction  and  review  of  the 
subject  of  designing  the  user-interface  of  a  terminal-oriented 
system.  There  is  no  guestion  that  this  subject  is  still  in  its 
infancy  and  that  the  next  few  years  should  see  a  large  growth  in 
the  literature  at  all  levels,  roughly  parallel  to  that  of 
programming  languages  and  compilers.  [CR18,352  J.  May] 


■■■  Parnas,  D.L.,  with  Courtois,  P.J.,  Heymans,  F.;  Concurrent 
Control  with  Readers  and  Writers;  CACM  14,10  (October  1971) 
pp. 66  7-6  6  8 . 


■■■  Parnas,  D.I.;  Information  Distribution  Aspects  of  Design 
Methodology;  IFIP  1971,  Nort h-Holland  (1972). 

In  this  short  paper  the  author  destroys  a  few  cherished 
preconceptions  or  myths  of  the  data- processing  community.  The 
primary  target  of  this  attack  is  the  idea  that  information  about 
a  complex  program  system  should  be  known  to  programmers  who  are 
implementing  the  system.  Instead  the  author  asserts  that 
improvements  in  maintainability,  flexibility,  and  reliability  can 
be  obtained  by  selectively  concealing  information.  Strangely 
enough,  this  reviewer  finds  that  the  argument  has  merit,  but 
needed  considerable  time  to  adapt  and  accept  the  idea  that 
secracy  is  its  own  reward. 

Selective,  controlled  distribution  of  information  can  be  an  asset 
during  a  system  implementation.  The  clever  programmer  who  "knows 
too  much"  can  improve  the  efficiency  of  his  own  code  by  taking 
advantage  of  "extra"  information.  Unfortunate  increases  in 
intermodule  dependency  will  usually  result,  thus  making  it 
difficult  to  change  only  one  module  when  a  change  is  required. 

One  question  remains  unanswered:  how  can  a  programmer  upgrade 
his  skill  to  become  a  system  designer  if  most  detailed  system 
design  information  is  always  concealed  from  him? 

[CR25,351  M.  Breslau] 

Parnas,  D.L.;  Some  Conclusions  from  an  Experiment  in  Software 
Engineering;  Proc.  of  the  FJCC  (1972). 
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A  loosely-knit  group  of  about  20  programmers  implemented  several 
versions  of  each  of  the  five  modules  of  a  small  software  system. 
Each  version  of  each  module  was  implemented  by  one  programmer  and 
tested  by  another.  Then,  selecting  combinations  of  one  version 
of  each  module,  synthesis  of  approximately  1000  distinct  systems 
was  possible.  This  permitted  study  of  a  reasonably  large  sample 
of  system  integration  operations. 

As  the  author  admits,  the  experiment  was  small,  and 
generalization  of  the  conclusions  must  be  done  with  caution.  At 
one  point,  certain  failings  of  FORTRAN  are  held  against  high- 
level  programming  languages  in  general.  However,  the  rest  of  the 
author's  observations  and  conclusions  yield  insight  and  are  well- 
presented.  Some  of  the  conclusions  are  surprising;  the  system 
integration  phase  can  be  painless;  system  implementation  can 
succeed  despite  programming  of  generally  poor  quality;  and 
limiting  a  programmer's  knowledge  of  the  remainder  of  the  system 
may  be  advantageous.  [CR25,506  K.C.Sevcik] 


■■■  Parnas,  D.L.;  Response  to  Detected  Errors  in  Well-Structured 
Programs;  Carnegie  Univ.  Technical  Report  (1972). 


Parnas,  D.L. ;  A  Technique  for  Software  Module  Specification, 
with  Examples;  CACM  15,5  (May  1972)  pp. 330-336. 


■aa  Parnas,  D.L.  and  Habermann,  A.N. ;  Comment  on  Deadlock 
Prevention  Method;  CACM  (September  1972) , 


a  a  a  Parnas,  D.L.;  On  the  Criteria  to  be  Used  in  Decomposing 
Systems  into  Modules;  CACM  (December  1972). 

The  desirability  of  breaking  programs  into  separate  modules  is 
well  known  and  generally  accepted,  however  hitherto,  little  has 
been  written  on  the  rules  for  determining  the  module  boundaries. 

The  author  contrasts  two  different  methods  of  dividing  a  KWIC 
Index  production  system  into  modules.  The  decomposition  that  is 
based  on  the  major  steps  as  seen  in  a  flowchart  view  of  the 
process  is  shown  to  be  much  less  amenable  to  subsequent  design 
changes  than  one  that  is  founded  on  -the  author's  criterion  of 
"information  hiding"  where  each  module  contains  some  piece  of  the 
design  that  is  known  only  to  itself.  The  module  interface 
specifications  contain  no  more  than  the  minimum  of  information 
required  by  the  caller  and  the  implementor.  The  less  these  two 
know  about  each  other's  module  the  better,  since  this  allows  the 
implementor  freedom  to  make  later  improvements  without  affecting 
the  caller,  and  also  permits  a  wider  variety  of  potential  callers 
thus  extending  the  usefulness  of  the  module.  As  a  consequence, 
for  example,  the  details  of  a  data  structure  and  its  access 
mechanism  should  be  kept  within  one  module  at  the  lowest  possible 
level.  This  principle  leads  to  a  hierarchical  structure  that 
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corresponds  closely  to  Dijkstra’s  concept  of  levels  of 
abstraction. 

One  problem  with  the  author’s  preferred  method  of  decomposition 
is  an  apparent  loss  of  understandability  of  the  process;  however, 
I  think  this  is  a  question  of  presentation  rather  than  it  being 
inherent.  Another  problem  with  this  method  is  that,  since  the 
rules  are  not  based  on  the  order  in  time  in  which  processing  is 
expected  to  take  place,  there  is  the  possibility  for  loss  of 
efficiency  due  to  heavy  linkage  overhead.  The  author  touches  on 
but  does  not  resolve  this  problem. 

Apart  from  the  point  noted,  the  paper  is  clearly  written  and  is 
recommended,  not  only  to  those  who  design  systems  but  also  to 
those  who  implement  the  modules,  since  its  precepts  should  be 
applied  at  all  levels.  [CR25,...  I. A.  Hollaar] 


■■■  Parnas,  D.L. ;  Sample  Man-Machine  Interface  Specification-A 
Graphics  Based  Line  Editor;  in  Haendler,  W.  and  Weizenbaum, 
J.(eds.),  Display  Use  for  Man  Machine  Dialog,  Carl  Hauser  Verlag, 
Munich  (1  972)  . 

This  paper  consists  of  a  description,  in  terms  of  a  series  of 
functions,  of  an  alphanumeric  CRT-based  text  editor,  and  a  brief 
(3  pages)  narrative  interpreting  the  functions.  These  are 
specified  in  terms  of  allowable  values,  initial  values,  pertinent 
parameters,  and  effects  of  certain  parameter  values. 

The  design  goal  for  this  text  editor  appears  to  be  the 
utilization  of  certain  CRT  console  features  not  found  in  printer¬ 
like  terminals,  e.g.,  split  screen,  scrolling,  and  line/character 
insert  and  delete.  This  is  reasonable  but  hardly  earthshaking! 
The  utility  of  this  paper  escapes  this  reviewer,  but  its  brevity 
is  appreciated.  [CR25,729  P.  Oliver] 


■■■  Parnas,  D.L.,  and  Price,  W.R.;  The  Design  of  the  Virtual 
Memory  Aspects  of  a  Virtual  Machine;  Proc.  of  the  ACM  SIGARCH- 
SIGOPS  Workshop  on  Virtual  Computer  Systems  (March  1973) • 


■■■  Parnas,  D.L.,  with  Cooprider,  L.W.,  Courtois,  P.J. ,  and 
Heymans,  F.;  Information  Streams  Sharing  a  Finite  Buffer:  Other 
Solutions;  Information  Processing  Letters  (July  1974). 


■■■  Parnas,  D.L. ;  On  A  Buzzword:  Hierarchical  Structure;  IFIP  74, 
North-Holland  Publishing  Co.  (1974)  pp. 336-339. 


■■■  Parnas,  D.L.,  Shore,  J.E.,  and  Elliot,  W.D.;  On  the  Need  for 
Fewer  Restrictions  in  Changing  Compile-Time  Environments;  Proc. 
of  the  International  Computing  Symposium,  North-Holland  (1975) 
pp.  4  5-48. 
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■■■  Parnas,  D. L. ;  Software  Engineering  or  Methods  for  the  Multi¬ 
person  Construction  of  Multi- version  Programs;  in  Goos,  G.  and 
Hartmanis,  J.  (eds.) ,  Lecture  Notes  in  Computer  Science  23, 
Springer-Verlag,  Berlin  (1975). 


■  Parnas,  D.L.,  and  Handzel,  G;  More  on  Specification 
Techniques  for  Software  Modules;  T. H.  Darmstadt,  Fachbereich, 
Informatik,  Germany,  Forschungsbericht  BS  I  75/1  (February  1975) . 


Parnas,  D.L. ;  On  the  Solution  of  the  Cigarette,  Smokers 
Problem  (Without  Conditional  Statements);  CACM  18,3  (March  1975) 
pp. 181-183. 

This  paper  contributes  to  our  understanding  of  the  computational 
power  of  the  P  and  V  primitives  on  semaphores.  The  author 
refutes  a  claim  made  by  Patil  that  a  synchronization  problem 
called  the  "cigarette  smoker's  problem"  cannot  be  solved  using  P 
and  V  operations  unless  conditional  statements  are  also  used  (see 
Patil,  S.S.,  "Limitations  and  capabilities  of  Dijkstra's 
semaphore  primitives  for  coordination  among  processes,"  Project 
MAC,  Computational  Structures  Group  Memo  57,  MIT,  Cambridge, 
Mass.,  Feb.  1971).  Using  semaphore  arrays,  the  author 
demonstrates  that  the  problem  can  be  solved  without  using 
conditionals.  He  also  argues  that  restrictions  prohibiting  the 
use  of  either  conditionals  or  arrays  are  artificial,  and  that  the 
implementation  of  Patil' s  generalized  operators  as  primitives  is 
not  justified. 

The  reader  will  be  disappointed  if  he  expects  to  find  a  statement 
relating  the  cigarette  smoker's  problem  to  the  problem  solved  in 
the  paper  -  this  is  left  to  the  reader's  imagination. 
[CR28,537  P.E.  Denning] 


Parnas,  D.L.;  The  Influence  of  Software  Structure  on 
Reliability;  International  Conference  on  Reliable  Software,  Los 
Angeles  (April  1975)  pp. 358-362. 


■■■  Parnas,  D.L.,  and  Siewiorek,  D.L. ;  Use  of  the  Concept  of 
Transparency  in  the  Design  of  Hierarchically  Structured  Systems; 
CACM  18,7  (July  1975)  pp. 401-408. 

This  article  reviews  several  methods  of  system  design,  then 
concentrates  on  the  concept  of  transparency  in  a  bottom-up  design 
process.  It  is  assumed  that  a  hierarchically  structured  system 
is  to  be  designed.  Under  the  further  assumption  that  a  well- 
defined  lower  level  of  software  (or  hardware)  called  a  base 
machine  has  been  designed,  the  design  of  the  next  level--the 
virtual  machine  is  considered.  A  virtual  machine  is  said  to  be 
completely  transparent  if  any  base  machine  state  sequence  can  be 
obtained  by  programming  the  virtual  machine.  Otherwise,  a  loss 
of  transparency  is  said  to  occur. 
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Some  effects  of  transparency  (or  its  loss)  on  virtual  machines 
are  shown  by  three  examples.  The  first  and  most  effective 
example  is  an  all  hardware  mechanical  system — the  steering  system 
of  a  four-wheeled  vehicle.  The  second  is  a  software  system, 
Markov  algorithm  machine.  The  third  is  a  hardware  example 
concerned  with  the  HP2116  computer. 

The  paper  concludes  with  a  discussion  of  an  unsolved  transparency 
problem  from  the  operating  system  area,  and  the  consideration  of 
several  more  general  transparency  questions.  This  paper  is  very 
general.  It  does  not  answer  any  questions  or  give  any  design 
techniques.  However,  it  might  stimulate  a  system  designer  to 
consider  more  carefully  the  degree  of  transparency  provided  in  a 
system  under  design.  [CR29,531  D.W.  Bray] 


mma  Parnas,  D.L.;  On  the  Design  and  Development  of  Program 
Families;  IEEE  Trans,  on  Software  Engineering  (March  1976) . 


■■■  Parnas,  D.L.,  Shore,  J.E.,  and  Weiss,  D.;  Abstract  Types 
Defined  as  Classes  of  Variables;  Proc.  of  the  Conference  on  Data; 
abstraction,  definition,  and  structure.  Salt  Lake  City  (March 
1976)  pp. 22-24. 


■  ■■  Randell,  B.  ,  with  Zurcher,  F.  W.  ;  Iterative  Multilevel 
Modelling:  A  Methodology  for  Computing  System  Design;  IFIP  1968, 
North-Holland,  (1969)  pp.  138-142. 

Apparently  the  authors  have  been  involved  in  a  methodology  for 
designing  computers  which  they  think  has  some  merit,  but  they 
don't  really  want  to  tell  us  anything  about  the  details.  They 
talk  in  generalities,  telling  us  that  the  most  effective  modeling 
is  one  which  has  several  level  of  communication.  There  are  no 
real  results  revealed  here.  [CR17,922  I.  Flores] 


Randell,  B.;  Highly  Reliable  Computing  Systems;  University  of 
Newcastle  Upon  Tyne,  Technical  Report  20  (1971). 


■■■  Randell,  B. ;  Operating  Systems:  The  Problems  of  Performance 
and  Reliability;  IFIP  71,  North-Holland  (1972)  pp. 281-290. 

This  is  a  position  paper.  The  author  starts  with  the  statement: 
Virtually  every  decision  taken  by  the  designers  and 

implementors  of  an  operating  system  has  the  potential  of 
having  a  significant  (and  in  the  present  state  of  our 
knowledge,  often  un forseeable)  effect  on  the  overall 

performance  and  reliability  of  the  system. 

He  then  goes  on  to  state  what  he  means  by  "per forme  nee"  and 
"reliability",  to  discuss  his  (somewhat  unconventional)  views  of 
what  the  major  problems  in  these  two  areas  are,  and  to  hint  at 
the  direction  he  thinks  solutions  to  these  problems  must  take. 
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I  think  the  paper  is  excellent ,  but  then  I  agree  with  the 
author’s  positions,  as  not  everyone  will.  Aside  from  its  being  a 
trifle  disorganized,  the  only  flaw  I  find  is  the  limitation 
implicit  in  the  inclusion  of  the  word  "operating"  in  the  title. 
Read  the  paper  and  find  out  what  he  has  to  say. 
[ CR2 5,107  D.C.  Walden] 


■■■  Randell,  B.;  System  Structure  for  Software  Fault-Tolerance; 
IEEE  Trans,  on  Software  Engineering  1,2  (June  1975)  pp.  220-”23 2. 

Computing  systems  today  are  implemented  in  many  levels — hardware, 
microprograms  (firmware) ,  operating  system  software,  and 
application  program  software.  The  relative  complexity  of 
software,  especially  in  the  operating  system  area,  accounts  for 
today’s  limited  state  of  the  art  in  error  recovery.  This  paper 
presents  a  neat  scheme  developed  by  a  research  project  at  the 
University  of  Newcastle-on-Tyne  for  structuring  software  for 
error  recovery.  The  scheme  involves; 

1)  RECOVERY  BLOCKS--write  programs  at  each  level  in  a 
computer  system  hierarchy  using  ALGOL-like  block  structure. 
For  each  block  provide  alternative  programs  to  accomplish  the 
block’s  task,  and  a  program  to  determine  if  the  results  are 
correct.  If  one  program  fails  the  test,  invoke  the  next 
alternative  one. 

2)  RECURSIVE  CACHE — in  order  to  invoke  alternative  programs, 
the  nonlocal  variables  which  are  changed  must  be  restorable. 
Implement  a  recursive  cache  scheme  (perhaps  using  virtual 
storage  techniques)  to  accomplish  this. 

3)  CON VERS  AT IONS — pro  grams  which  run  in  parallel,  but  which 
are  dependent  need  common  recovery  blocks  during  the  time 
they  are  dependent.  Proper  nesting  of  such  recovery  blocks, 
called  "conversations,"  provides  the  interprogram 
communication  structure  needed  for  error  recovery. 

4)  INTERPRETERS — instructions  at  one  level  of  the  computing 
system  hierarchy  are  "interpreted"  by  the  next  lower  level. 
An  interpreter  which  implements  recovery  blocks  and  recursive 
caches,  and  properly  handles  error  between  levels  is 
described . 

This  paper  is  recommended  reading  for  all  designers  of  computing 
systems.  [CR29,546  J.W.  Snively,Jr] 


■■■  Reynolds, J. C. ;  Definitional  Interpreters  for  Higher- 
ordeProgramming  Languages.  in  Proc.  ACM  1972  Annaual  Conference, 
ACM,  New  York,  717-740.  See  main  entry  CR13,12  (Dec.  1972), 
Rev. 24,148. 

What  methods  are  there  for  giving  a  precise  meaning  to  a  high- 
level  programming  language?  The  requirement  for  precision  rules 
out  the  original  natural-language  descriptions  of  FORTRAN  and 
ALGOL  60,  for  example.  The  earliest — and  most  unsatisf actory-- 
method  of  precise  definition  was  to  write  a  compiler;  the  meaning 
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of  a  FORTRAN  program  was  just  what  happened  when  it  was  compiled 
and  run  on  a  particular  machine.  This  approach  has  many 
disadvantages,  and  need  not  concern  us  further. 

The  second  and  most  frequently  used  method  is  to  write  an 
interpreter  for  the  language  in  some  other  language.  The 
definitions  of  LISP,  PL/I,  and  ALGOL  68  (insofar  as  the  latter  is 
precise)  use  this  method,  which  of  course  raises  the  question  of 
giving  meaning  to  the  defining  language  itself.  The  third  and 
most  recent  approach  is  to  assign  to  each  program  in  the  language 
to  be  defined  (we  will  use,  as  the  author  does,  the  terms 
"defined  language"  and  "defining  language")  an  object  in  a  purely 
mathematical  domain  of  discourse  as  its  meaning.  This  approach 
was  pioneered  by  C.  Strachy,  and  given  full  justification  by  D. 
Scott  in  his  recent  work  on  continuous  functions  and  models  of 
the  lambda-calculus. 

The  present  paper  is  a  thorough,  lucidly- written,  selfcontained 
and  well-documented  study  in  the  second  approach.  The  author 
does  not  undertake  to  discuss  fully  the  usefulness  of  this 
approach,  or  to  defend  it  against  the  charge  of  infinite  regress, 
except  to  say  that  insofar  as  the  defining  language  is  better 
understood,  it  serves  to  elucidate  the  defined  language.  It  may, 
therefore,  be  worthwhile  to  attempt  to  give  briefly  some  reasaons 
why  the  second  approach  has  usefulness,  in  case  anyone  were  to 
suggest  that  it  is  no  longer  necessary,  now  that  we  can  by  the 
third  approach  refer  all  programming  languages  immediately  to 
mathematics.  First,  to  define  one  language  in  another  can 
elucidate  the  relationship  between  the  two  languages;  for 
example,  an  interpreter  for  ALGOL  60  written  in  FORTRAN  would 
have  to  work  hard  to  model  features  of  the  former  not  directly 
matched  in  the  latter.  Second,  one  might  accept  a  particular 
language  (e.g.,  the  lambda-calculus,  ignoring  the  fact  that  we 
now  have  Scott's  mathematic  models  for  it)  as  the  canonical 
defining  language,  and  refer  all  other  languages  to  it,  the 
advantage  here  being  that  one  has  used  less  mathematics;  the 
approach  is  more  "finistic".  Third,  insofar  as  the  interpreter 
uses  objects  of  a  concrete  nature  (rather  than  functions  of  high 
type)  to  model  the  execution  of  a  defined  language  program,  such 
an  interpreter  may  serve  as  a  useful  guideline  for  the 
implementation  of  a  compiler  for  the  defined  language.  One  of 
the  author's  achievements  in  the  present  paper  is  to  show  how 
such  a  concrete  interpreter  can  be  derived  systematically  from 
one  which  uses  higher  type  functions  freely.  Finally, 
interpreters  by  their  concisness  and  (often)  elegance  are 
appealing  to  human  beings. 

The  author  begins  with  a  four-way  classification  of  interpreters 
(not  of  the  languages  in  which  they  are  written)  as  to  whether 
they  use  higher-order  functions,  and  whether  the  meaning  of  the 
interpreter  (that  is,  the  meaning  that  it  ascribes  to  the  defined 
language)  depends  on  the  order  of  application  call-by-name  or 
call-by-value--chosen  for  the  defining  language.  His  implication 
I  think  is  that  the  second  criterion  in  one  sense  separates  the 
sheep  from  the  goats;  an  interpreter  that  is  not  order-of- 
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application-dependent  is  stable  under  some  changes  in  the 
definition  of  the  defining  language.  However,  an  interpreter 
that  uses  higher-order  functions  benefits  from  clarity  and  lack 
of  arbitrary  choice  of  representation;  one  that  does  not  benefits 
from  conceptual  parsimony  and  implementation-orientedness;  and 
neither  is  better. 

After  giving  the  abstract  syntax  of  a  simple  applicative 
language — let  us  call  it  L — the  author  gives  his  first 
interpreter  written  in  L  and  defining  a  language  L'  (a  mild 
restriction  of  L) •  That  L  and  I*  are  nearly  the  same  is  not 
relevant;  the  author  gives  the  interpreter  as  an  example  of  the 
failure  to  elucidate  the  features  of  one  language  by  those  of 
another,  simply  because  each  feature  of  the  defined  language  is 
interpreted  by  the  corresponding  feature  of  the  defining 
language;  higher-order  functions  by  high-order  functions,  call- 
by-name  by  call-by-name,  call-by- va lue  by  call-by-value. 

He  proceeds  then  to  transform  his  first  interpreter  into  others, 
one  in  each  of  the  four  classes,  in  a  way  which  is  systematic 
enough  to  give  hope  that  it  would  be  applicable  in  more  complex 
language  situations.  The  technique  of  eliminating  high-order 
functions  is  to  introduce  record  streuc tures-the  most  important 
being  closure  (in  the  sense  of  Landine--to  represaent  values  that 
are  functions.  To  eliminate  order-of-application  dependence  and 
thereby  get  a  faithful  description  of  call-by-value  L1 
independently  of  the  calling  mechanism  of  L,  the  device  of 
continuations  (recently  proposed  more  or  less  simultaneously  by 
L. Morris  and  by  C. Wadsworth)  is  used. 

Indeed,  the  paper  seems  to  be  the  first  readily  accessible 
exposition  of  continuations,  and  serves  as  a  useful  reference  for 
this  topic.  The  value  of  continuations  is  that  they  not  only 
provide  a  way  of  describing  the  call-by-value  mechanism,  but  also 
handle  other  f low-of-control  mechanisms,  in  particular,  labels, 
jumps,  and  escape  from  procedures  other  than  by  "return".  The 
author  illustrates  this  by  adding  an  escape  mechanism  to  L'  and 
extending  his  interpreter  (not  extending  L)  to  describe  it.  One 
impotant  point  which  he  does  not  bring  out  (it  is  relevant  to 
continuations  but  nocentral  to  his  topic)  is  that  they  are  purely 
mathematical  devices,  and,  as  such,  are  useful  in  giving  a  purely 
mathematical  semantics  to  f low-of-control  features;  in  fact,  to 
date  no  satisfactory  alternative  method  is  available  for  jumps. 

The  final  extention  to  L'  is  the  addition  of  assignment 
statements;  again,  the  four  interpreters  arew  shown  to  be 
extendible  (with  L  still  unchanged)  to  yield  the  appropriate 
semantics . 

It  is  difficult  to  find  fault  with  this  paper.  It  will  repay 
careful  study  by  people  already  working  in  the  field,  and  for 
others  it  constitutes  a  very  nonsuperficial  introduction. 

[ CF25,229  A.J.B.G.  Milner] 
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■  ■■  Reynolds,  J.C.;  Toward  a  Theory  of  Type  Structure;  Colloquium 
on  Programming,  Paris  (April  1974). 


■■■  Reynolds,  J.C. ;  User-Defined  Types  and  Procedural  Data 
Structures  as  Complementary  Approaches  to  Data  Abstraction; 
Conference  on  New  Directions  in  Algorithmic  Languages,  IFIP, 
Munich  (August  1975). 


an  Ross,  D.T.;  PANEL:  what*s  special  about  MOL's?;  in  Machine 
oriented  higher-level  languages  (Proc.  IFIP  Working  Conference  on 
Machine  Oriented  Higher  Level  Languages),  W.L.  van  der  Poel  and 
L . A.  Maarssen (Eds. ) ,  North-Holland  Publ.  Co.,  Amsterdam,  The 
Netherlands,  1974,  107-125.  See  main  entry  CR16,2  (Feb. 1975), 
Rev. 27,824. 

This  entertaining  article  appears  to  be  a  transcript  of  a  live 
panel  discussion  attempting  to  define  Machine  Oriented  Languages 
(MOLs) ,  Systems  Implementation  Languages  (SILs) ,  their 
differences,  and  their  similarities.  The  three  panelists. 
Horning,  Ichbiah,  and  Knobe  offer  their  ideas,  and  then  the 
discussion  switches  to  the  floor;  the  chairman  (noted  here  as 
author)  occasionally  exercises  his  perogative  to  interrupt. 
Horning  deals  with  the  need  for  high-levelness  primarily  to 
promote  a  proper  style  of  hierarchical  programming.  Ichbiah 
agrees  with  the  need  for  high-levelness,  but  points  out  that 
certain  problems,  such  as  programming  memory  management,  require 
low-level  features.  Knobe  complains  that  people  ,  at  the 
conference  have  really  been  talking  about  SILs  instead  of  MOLs 
(as  the  conference  title  would  suggest).  He  notes  that  the 
things  that  MOL  people  want  (e. g. ,  efficiency)  are  also  desired 
by  others  (e.g.,  numerical  analysts).  Thus  what  is  really  needed 
by  all,  is  a  good  general  purpose  language  capable  of  efficient 
execution.  In  the  ensuing  discussion,  it  was  pretty  much  agreed 
that  the  search  for  the  one  "Holy  MOL"  will  fail,  because  it  is 
too  difficult  to  reconcile  the  high-level  and  low-level  needs, 
and  the  differences  between  specific  machines.  Perhaps  the 
direction  to  follow  is  use  of  a  MOL  for  each  class  of  machine,  or 
to  use  high-level  languages  for  95$  of  the  code,  reserving  MOLs 
or  assembly  languages  for  the  machine-oriented  5$  of  the  code. 

The  discussion  brings  out  enough  of  the  personalities  of  the 
participants  to  involve  the  reader  himself,  in  the  discussion, 
and  he  may  even  find  himself  writing  his  own  comments  in  the 
margin  of  the  book!  [CR28,251  D. M.  Berry] 


■■■  Ross,  D.T.;  Fourth  Generation  Software:  A  Building  Block 
Science  Replaces  Hand-Crafted  Art;  Computer  Decisions  2  (April 
1970)  pp. 32-38. 
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■■■  Ross,  D.T.;  Uniform  referents:  an  Essential  Property  for  a 
Software  Engineering  Language;  In  Software  Engineering,  Vol. 1, 
1970,  91-101.  See  main  entry  CR12,5  (Hay  1971),  Rev. 21,218. 

A  general-purpose  programming  language  that  is  to  be  used  as  the 
expressive  vehicle  for  all  software  engineering  activities  must 
fulfill  one  basic  criterion:  that  is,  a  single  uniform  referent 
mechanism  must  be  used  for  all  references  to  operands.  The 
necessity  of  the  criterion  is  demonstrated  by  employing  the 
outside-in  scheme  of  software  design  which  first  states  the 
problem  in  general  terms  and  then  gives  those  terms  meaning  by 
providing  more  and  more  detail.  Programs  are  thus  classified 
into  various  levels  such  that,  in  general,  the  lower  level  is  a 
refinement  of  the  upper  one.  Thus,  in  order  for  the  programs  of 
an  upper  level  to  remain  completely  unchanged  as  interface 
programs  change  to  accomodate  various  forms  of  interlevel  detail, 
the  operands  must  be  referenced  in  a  uniform  manner. 

Two  dual  graphic  models  for  visualizing  the  structure  of  the 
outside-in  design  are  presented.  They  are  very  interesting  and 
helpful.  At  a  time  when  extensions  to  the  software  engineering 
discipline  are  so  drastically  needed,  such  a  contribution  is  very 
welcome.  [CR21,883  I.N.  Chen] 


■■■  Ross,  D.T.,  Goodenough,  J.B.,  and  Irvine,  C. A. ;  Software 
Engineering:  Process,  Principles,  and  Goals;  Computer  (May  1975). 


Ross,  D.T.;  Structured  Analysis:  A  Language  for  Communicating 
Ideas;  IEEE  Trans.  on  Software  Engineering  Vol.SE-3,  No. 1 
(January  1977)  pp. 16-34. 


■■■  Ross,  D.T.  and  Schoman,  K.E.,  Jr.;  Structured  Analysis  for 
Requirements  Definition;  IEEE  Trans.  on  Software  Engineering 
Vol.SE-3,  No. 1  (January  1977)  pp.6-15. 


■■■  Seegmueller,  G. ;  Systems  Programming  as  a  Discipline;  Proc. 
IF IP  Conference  on  Programming  Teaching  Techniques,  Zakopane, 
Poland,  North-Holland  (1973)  pp. 157-159. 


■■■  Seegmueller,  G. ;  Systems  Programming  as  an  Emerging 
Discipline;  IFIP  1974,  Stockholm,  North-Holland  (1974)  pp. 419- 
426. 


■■■  Seegmueller,  G. ;  Einfuehrung  in  die  Systemprogrammierung 
(Introduction  to  Systems  Programming) ;  Bl-Verlag,  Mannheim  (1974) 
4  80p,  (German) . 
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■■■  Seegmuellerr  G. ;  Language  Aspects  in  Operating  Systems;  NATO 
Advanced  Study  Institute  Lectures,  Marktoberdorf  (1975). 


■  ■■  Seegmueller,  G. ,  with  Hegering,  H.-G.,  Schneider,  D., 
Schwald,  A.;  Systems  Programming  Elements  of  the  Language  ASTRA; 
Proc.  Eurocomp.  London  (September  1976) . 


■■■  Teitelman,  W. ;  Toward  a  Programming  Laboratory;  in  Software 
Engineering  Techniques,  NATO  (1970)  pp. 137-149. 

This  paper  discusses  the  feasibility  and  desirability  of 
constructing  a  "programming  laboratory"  which  would  cooperate 
with  the  user  in  the  development  of  his  program,  freeing  him  to 
concentrate  more  fully  on  the  conceptual  difficulties  of  the 
problem  he  wishes  to  solve.  Experience  with  similar  systems  in 
other  fields  indicates  that  such  a  system  would  significantly 
increase  the  programmer’s  productivity. 

The  PILOT  system,  implemented  within  the  interactive  BBN  LISP 
system,  is  a  step  in  the  direction  cf  a  programming  laboratory. 
PILOT  operates  as  an  interface  between  the  user  and  his  programs, 
monitoring  both  the  requests  of  the  user  and  the  operation  of  his 
programs.  For  example,  if  PILOT  detects  an  error  during  the 
execution  of  a  program,  it  takes  the  appropriate  corrective 
action  based  on  previous  instructions  from  the  user.  Similarly, 
the  user  can  give  directions  to  PILOT  about  the  operation  of  his 
programs,  even  while  they  are  running,  and  PILOT  will  perform  the 
work  required.  In  addition,  the  user  can  easily  modify  PILOT  by 
instructing  it  about  its  own  operation,  and  thus  develop  hiw  own 
language  and  conventions  for  interacting  with  PILOT.  Several 
examples  are  presented.  [CR20,297  Abstract] 


■■■  Teitelman,  W. ;  Do  What  I  Mean;  The  Programmer's  Assistant; 
Computers  and  Automation  21  (April  1972)  pp.8-11. 


■■■  Teitelman,  W. ;  Automated  Programming  the  Programmer's 
Assistants;  FJCC  (1972)  pp. 917-921. 


■■■  Teitelman,  W. ;  Clisp;  Conversational  Lisp;  IEEE  Trans,  on 
Computers  C-25,4  (April  1976)  pp. 354-357. 


■■■  Turski,  W.M.;  A  Model  for  Data  Structures  and  its 
Applications-Part  I;  Acta  Informatica  1,1  (1971)  pp. 26-34. 


■■■  Turski,  W.M.;  A  Model  for  Data  Structures  and  its 
Applications-Part  IT;  Acta  Informatica  1,4  (1972)  pp. 282-289. 
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■■■  Turski,  W.M.;  A  Correspondence  Between  Thesaurus-Based  and 
Multi-Attribute  Retrieval  Systems;  Information  Storage  and 
Retrieval  8,6  (Dec.  1972),  309-313. 

This  paper  establishes  the  abstract  mathematical  relationship 
between  query  processing  in  thesaurus-based  information  retrieval 
systems  and  multi-attribute  retrieval  systems.  The  equivalence 
relationship  is  established  by  showing  that  the  theoretical  model 
of  the  thesaurus-based  information  retrieval  system  can  be 
expressed  in  a  form  which  is  equivalent  to  the  problem  statements 
for  the  multi-attribute  retrieval  system. 

The  author  maps  document  descriptions  into  composite  names.  Then 
query  processing  in  a  thesaurus-based  information  retrieval 
system  is  shown  to  be  equivalent  to  query  processing  in  the 
multi-attribute  system  by  the  relationship: 

0  (t)  e  N  (r)  <— >t  6  T  (r) 

0 (t)  is  the  composite  name  into  which  the  document  description  t 
is  mapped.  N (R)  is  a  set  of  s-composite  names.  T  (r)  is  the 
subset  of  the  thesaurus  defined  for  the  query  r. 
[ CR2 5 ,4  73  G.  Jahoda] 


•  «b  Turski,  W.  M.  ;  Einige  Probleme  der  Programmier ung  von 
Elekt ronischen  Rechenmaschienen;  Wissenschaft  und  Menschheit, 
Eand  10,  Urania-Verlag,  Leipzig/Jana/Berlin  (1974)  pp. 324-331. 


■■■  Wirth,  N. ;  Program  Development  by  Stepwise  Refinement;  CACM 
14,4  (April  1971)  pp.  221-227. 

This  paper  is  mainly  concerned  with  the  problem  of  teaching 
people  how  to  formulate  programs.  The  author  advocates  a  better 
method,  which  is  more  systematic  and  helps  to  give  students  an 
insight  into  the  decisions  that  go  into  the  making  of  a  program. 

The  method  is  as  follows:  A  nontrivial  problem  is  taken,  and  the 
first  step  is  to  produce  a  solution  in  general  terms,  begging 
questions  of  detail.  This  solution  is  gradually  refined  and 
improved  by  filling  in  details  at  successively  lower  levels,  each 
step  in  the  process  being  the  result  of  a  conscious  design 
decision,  perhaps  involving  judgement  of  merits  of  alternative 
solutions.  The  process  continues  until  a  stage  is  reached  such 
that  the  specification  of  the  solution  to  the  problem  is  at  a  low 
enough  level  to  be  encoded  in  a  high-level  programming  language. 
Decisions  about  data  formats  would  be  made  toward  the  end  of  this 
process,  and  would  be  taken  in  parallel  with  decisions  about  the 
more  exact  details  of  the  problem  solving  method.  At  this  stage, 
questions  of  efficiency  in  time  and  storage  would  arise.  These 
ideas  are  illustrated  by  applying  the  method  to  the  8  Queens 
Problem. 
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Finally,  it  is  concluded  that  if  the  method  is  applied 
skillfully,  it  will  make  the  program  that  is  its  end  product  both 
portable  and  easy  to  maintain.  The  method  is  therefore 
applicable  as  a  working  tool  as  well  as  a  tutorial  tool. 
[CR21,631  J.P.  Brown] 


■■■  Wirth,  N. ;  The  Design  of  a  PASCAL  Compiler;  Software- Practice 
and  Experience  1,4  (October-December  1971)  pp. 309-333. 

This  paper  discusses  the  bootstrap  implementation  of  the  PASCAL 
compiler  in  its  own  language.  PASCAL  is  a  simple  algorithmic 
language  patterned  after  ALGOL  60  with  an  elegant  facility  for 
describing  and  manipulating  data  structures. 

The  compiler  itself  is  written  in  a  straightforward,  conventional 
manner  suitable  for  its  intended  use  as  a  "classteaching "  tool. 
It  is  a  one-pass,  in-core,  deterministic,  recursive-descent 
compiler,  with  a  lexical  scanner,  that  generates  nonrelocatable 
object  code.  The  good  use  of  "engineering  intuition"  in  the  many 
design  decisions  discussed  make  this  paper  well  worth  reading. 

However,  the  arguments  to  show  that  PASCAL  and  its  compiler  are 
"efficient"  are  unconvincing  (in  spite  of  the  predisposition  of 
this  reviewer) .  The  examples  show  mostly  that  there  is  a  poor 
ALGOL  60  compiler  in  the  CDC6400,  that  FORTRAN  IV  still  can't 
handle  recursive  problems,  and  that  the  (in) efficiencies  of  run¬ 
time  support  routines  can  dominate  whatever  code  is  generated  by 
a  compiler.  PASCAL  code  does  compete  creditably  with  the  FORTRAN 
code  in  some  examples. 

One  point  left  unexplained  is  the  mediocre  speed  of  the  compiler 
(100  lines/sec  on  at  least  1  million  instruction  per  second 
machine) .  Compilers  exist  which  are  much  faster  than  this  with  a 
more  complicated  source  language.  Perhaps  the  use  of  a  linearly 
searched  symbol  table  contributed  to  this  problem  (hashing 
algorithms  can  be  cumbersome  in  machine-independent  form) . 

The  paper  contains  many  interesting  comments  on  such  topics  as 
bootstrapping,  the  relationship  of  machine  architecture  to 
compiler  complexity,  a  simple  implementation  of  a  display, 
loaders  vs.  fast  compilers,  and  others.  The  comment  that  loaders 
are  not  needed  if  the  compiler  is  fast  enough  is  well  taken,  but 
not  well  supported  by  the  evidence  of  the  PASCAL  compiler 
"loading"  a  19,999-word  program  in  40  seconds. 

In  general,  the  paper  exhibits  the  application  of  good  design 
sense  and  is  recommended  for  both  students  and  professional 
compiler  writers.  [CR23,196  J.T.  O'Neil] 


■■■  Wirth,  N.;  The  Programming  Language  PASCAL;  Acta  Infcrmatica 
1  (1971)  pp. 35-63. 
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■■■  Wirth,  N. ;  Systematic  Programming:  An  Introduction;  Prentice- 
Hall,  Englewood  Cliffs,  N.  J.  (1973) . 

The  book  teaches  basic  programming  according  to  the  following 
principles: 

1)  Programs  should  be  written  with  a  view  of  analytic 
verification. 

2)  The  form  of  a  program  should  mirror  its  logical  structure 
(i.e. ,  GOTOs  should  be  avoided  where  possible) . 

3)  Subroutine  structure  is  indispensable  in  organizing  the 
program  into  its  significant  components. 

4)  Average  cost  of  operation  shoulH  be  minimized 

The  text  seems  best  suited  for  an  introductory  one-semester 
programming  course  for  math  and  computer  science  oriented 
students.  Sufficient  background  would  be  a  year  of  calculus  and 
seme  familiarity  with  elementary  propositional  logic. 

An  implementation  of  PASCAL  is  very  desirable,  as  the  book  uses 
its  notation  heavily,  and  the  form  of  its  statements  corresponds 
well  to  concepts  taught  in  the  book. 

Introduction  to  a  great  deal  of  computer  science  vocabulary  is 
provided,  along  with  relevant  historical  notes,  an  introduction 
to  complexity  analysis,  a  discussion  of  data  structures,  and  some 
mention  of  problems  involved  in  constructing  editors  and 
compilers.  Exercises  are  straightforward  and  illustrative  rather 
than  "tricky.” 

Care  will  be  reguired  of  the  instructor  when  teaching  the  section 
on  program  verification;  they  appear  more  difficult  than  the 
other  sections,  and  will  probably  need  to  be  supplemented  with 
additional  examples.  Specifically,  the  book  does  not  make  clear 
how  much  of  the  process  of  selecting  assertions  should  be 
automatic  and  how  much  is  art,  and  the  examples  fail  to 
demonstrate  the  selection  process  coherently.  No  mention  is  made 
of  the  difficulties  involved  in  verifying  programs  using  real 
a  rithmetic. 

Some  lack  of  precision  will  have  to  be  remedied  by  the  instructor 
(e.g.,  the  regular  set  recognition  algorithm,  14.3,  is 
incompletely  specified),  but  on  the  whole,  the  book  provides  a 
very  reasonable  introduction  to  computer  science. 

[ CF26 , 477  N. A .  Lynch] 


■■■  Wirth,  N. ;  On  The  Design  of  Programming  Languages;  in  IFIP 
Congress  74,  Vol.2:  Software,  1974,  386-393.  See  main  entry 

CP27, 811 . 

This  paper  should  be  read  by  all  prospective  designers  of 
programming  languages.  While  some  of  the  design  issues  presented 
and  their  practical  realization  are  bound  to  controversial,  the 
author  gives  a  valuable  overview  of  the  designer's  problems. 
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based  on  his  considerable  experience.  He  rejects  the  idea  of 
"simplicity  through  generality"  and  makes  the  following  points. 

Conciseness  and  lack  of  redundancy  is  not  necessarily  a  virtue. 
It  is  not  enough  to  minimize  the  number  of  basic  features  in  a 
language  — *  they  must  also  be  kept  free  from  unexpected 
interactions.  The  author  discusses  three  features  of  languages 
that  cause  problems  because  of  excess  generality,  and  suggests 
how  languages  can  be  improved  by  restricting  this  generality. 
The  features  are: 

1)  Jumps:  An  argument  of  the  "goto  considered  harmful" 
category  is  made,  and  the  structured  statements  of  PASCAL 
(while  B  do  S,  repeat  S  until  B,  the  case  statement)  are 
proposed  as  a  remedy. 

2)  Type-less  operands:  The  "better  idea"  is  that  the  concept 
of  static  data  types  allows  checking  for  inconsistencies  at 
compile  time,  thereby  enhancing  programming  security  and  run¬ 
time  efficiency. 

3)  Free  address  manipulation:  The  unrestricted  use  of 
references  is  criticized,  ALGOL  68  being  cited  as  a  prime 
offender.  Some  of  the  restrictions  needed  are  allowing 
pointers  to  point  only  to  objects  of  a  single  type,  and 
avoiding  automatic  "coercion." 

A  fundamental  principle  espoused  by  the  author  is  that  the  text 
with  another  compiler  on  an  IBM  360/370  system.  But  it  would 
require  a  more  ambitious  instructor  to  use  the  text  with  a 
different  system.  [CR27,842  D.E.  Denning] 


■■■  Wirth,  N. ;  On  the  Composition  of  Well-Structured  Programs; 
Computing  Surveys  6,4  (December  1974)  pp. 247-259. 

This  paper  contains  three  sections  and  a  conclusion.  Section  1, 
entitled  "Intellectual  Manageability  of  Programs,"  describes  the 
method  of  stepwise  refinement  in  program  development.  Since 
programming  tasks  are  growing  more  complex,  it  is  essential  to 
develop  effective  program  management  tools.  Under  the  refinement 
technique,  a  program  is  regarded  on  an  abstract  level  performing 
its  tasks  on  abstract  data  and  expressed  in  some  suitable 
notation,  possibly  in  natural  language.  The  constituents  of  the 
program  are  then  subjected  to  repeated  refinement  to  lower  levels 
of  abstraction  until  a  level  is  reached  which  is  understandable 
to  the  computer,  that  is,  a  level  written  in  a  programming 
language.  Clearly,  the  manageability  criterion  rests  on  the 
assumption  that  the  constituent  operations  are  sufficiently 
simple  to  connect  and,  in  fact,  should  be  developed  as  operations 
with  single  starting  and  ending  points.  Moreover,  the 
composition  of  each  constituent  must  also  be  simple. 

The  selection  of  the  appropriate  programming  structures  is  the 
subject  of  Section  2,  "Simplicity  of  Composition  Schemes." 
Essentially,  the  idea  is  to  use  such  statememnts  as  the  WHILE  and 
REPEAT  and  to  shun  GOTO's.  The  author  stresses  that 
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...well  structured  programs  should  not  be  obtained  merely 
through  the  formalistic  process  of  eliminating  GOTO 
statements  from  programs  that  were  conceived  with  the 
facility  in  mind,  but  that  they  must  emerge  from  a  proper 
design  process... 

To  stress  this  point.  Section  3,  "Loop  Structures,"  contains  two 
examples  which  demonstrate  that  often  the  exit  from  the  middle  of 
the  loop  construct  is  based  on  preconceived  notions  rather  than 
on  a  real  need.  Indeed,  even  better  solutions  can  occasionally 
be  obtained  by  adhering  to  the  fundamental  constructs  described 
in  Section  2.  Finally,  the  author  reiterates  his  previous 
arguments  for  well- structured  program  composition,  and  laments 
the  absence  of  a  structured  programming  language  as  widely 
available  as,  say,  FORTRAN,  in  the  conclusion. 

This  article  is  extremely  well-written  and  certainly  a  welcome 
addition  to  the  literature  of  good  programming  style.  It  should 
be  required  reading  in  every  programming  language  course. 
[ CR28, 101  S.  Chen] 


■■■  Wirth,  N. ;  From  Programming  Techniques  to  Programming 
Methods;  in  Proc.  International  Computing  Symposium,  Davos, 
Switzerland,  September  1973,  North- Holland  (1974). 


■■■  Wirth,  N.,  and  Jensen,  K. ;  PASCAL--User  Manual  and  Report; 
S pringer- Verlag,  New  York,  1974,  Paperback. 

As  the  title  implies,  this  book  is  intended  as  a  user  reference 
manual  for  the  programming  language  PASCAL.  As  such  this  book 
contains  many  more  examples  than  does  the  original  report  on 
P ASCAL[ 1  ] .  To  use  this  manual  the  reader  should  already  have  a 
basic  knowledge  of  programming  and  of  at  least  one  programming 
language,  preferably  ALGOL.  A  more  basic  text  in  programming 
using  PASCAL  is[2]. 

In  a  very  real  sense  PASCAL  can  be  regarded  as  both  a  cleanup  and 
an  extension  of  ALGOL.  However,  it  is  not  just  another  ALGOL- 
like  language,  but  rather  an  important  new  language.  As  such,  it 
is  noted  for  its  use  of  strong  typing.  the  use  of  the  type 
declareation  to  create  both  new  type  and  atructures,  the 
declaration  and  use  of  subranges,  and  the  notion  of  sets  as  a  way 
of  incorporating  bit  manipulation  in  a  machine-independent 
manner.  PASCAL  has  already  generated  a  considerable  discussion 
in  the  literature  and  has  been  adopted  by  a  number  of 
universities  as  "the"  introductory  programming  language. 

Chapter  0  serves  as  an  introduction  to  the  manual.  Chapters  1-12 
are  devoted  to  standard  PASCAL,  while  chapters  13-14  are  devoted 
to  PASCAL-6000  (for  the  CDC  computers).  A  number  of  useful 
appendices  containing  standard  procedures  and  functions, 
operators,  syntax  diagrams,  error  messages,  and  examples  are 
included.  In  addition,  the  entire  revised  report  on  PASCAL  is 
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included.  Separate  indexes  for  both  the  manual  proper  and  the 
revised  report  are  provided. 

The  manual  is  basically  well  written  and  contains  very  few 
typographical  errors.  Numerous  examples  are  provided,  although 
occasionally  they  are  too  elever  (for  example,  program  minaax2, 
page  68) .  Another  major  criticism  is  that  one  is  forced  to  turn 
to  the  appendix  for  precise  definitions  of  the  proper  syntax,  for 
example,  and  for  a  list  of  simple  and  structured  statements 
(page  20) .  The  authors  also  occasionally  ignore  or  redefine 
standard  terminology.  In  the  latter  case,  for  example,  the  use 
of  the  terms  "static"  and  "dynamic  allocation"  (page  63)  is 
improper  since  the  correct  terms  are  dynamic  and  controled 
allocation,  respectively.  Similarly,  PASCAL  passes  parameters  by 
either  value  or  reference,  but  the  authors  refuse  to  use  the 
latter  term  (page  71),  preferring  instead  to  define  by  example. 
I  would  also  have  preferred  the  term  "compound  statement"  rather 
than  "structured  statement"  (page  20) . 

Other  criticisms  include  the  fact  that  the  restrictions  on  the 
use  of  the  goto  are  not  adequately  explained.  The  authors 
occasionally  use  a  feature  in  an  example  program  before  it  has 
been  introduced.  Finally,  all  programs  produce  only  unlabeled 
output  (which  does  not  set  a  good  example  of  style). 

The  manual  is  clearly  useful  to  those  programming  in  PASCAL,  or 
for  those  who  wish  to  pick  up  a  reading  knowledge  of  PASCAL.  I 
strongly  recommend  a  knowledge  of  PASCAL,  and  the  debate 
concerning  it  to  all  designers  of  programming  languages. 
[ CR28  , 477  R.E.  Noonan] 
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■■■  Wirth,  N.;  An  Assessment  of  the  Programming  Language  PASCAL; 
IEEE  Trans,  on  Software  Engineering  1,2  (June  1975)  pp. 192-198. 

The  evaluation  of  a  given  work  by  its  own  author  is  not  a 
frequent  matter  in  computer  science,  especially  when  this  work 
has  already  given  rise  to  some  controversy.  Thus,  it  is  very 
interesting  and  refreshing  to  read  critical  comments  on  the 
programming  language  PASCAL,  made  by  its  own  designer.  This 
evaluation  is  made  in  the  light  of  software  reliability,  and 
obviously  does  not  concern  only  criticisms  of  the  language;  it  is 
made  in  a  very  lucid  and  impartial  fashion,  which  yields  general 
guidelines  for  the  design  of  programming  languages  and 
programming  tools.  The  paper  is  easy  and  pleasant  to  read,  and 
contains  some  well  coined  sentences  (often  provocative) ,  worthy 
of  quotation  at  the  end  of  this  review. 
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The  author  begins  by  discussing  the  notion  of  program 
reliability,  and  suggesting  that  program  correctness  is  a  much 
more  valid  notion:  "...the  degree  to  which  a  program  is 
unreliable  is  exactly  the  probability  with  which  its  incorrect 
parts  are  executed."  A  brief  list  and  description  is  then  made 
of  the  most  important  features  of  PASCAL  which  contribute  to 
reliable  programming  by  providing  useful  redundancy;  these 
include  the  symbolic  scalar  types,  record  types,  set  types, 
subrange  types,  and  the  simple  forms  of  iterative  and  selective 
statements.  The  rest  of  the  paper  discusses  the  main 
deficiencies  of  the  language;  some  of  these  have  already  given 
rise  to  controversy,  others  have  remaind  unnoticed  by 
commentators  without  experience  in  the  language.  These  latter 
points  include  operator  precedence,  the  goto  statement,  the 
restrictions  on  array  bounds  in  declaration  and  parameter 
specifications,  the  concept  of  file,  and  the  notion  of 
discriminated  or  free  type  unions. 

The  discussion  is  easy  to  follow,  even  by  a  reader  unfamiliar 
with  PASCAL  (and  equally  interesting  for  that  sort  of  reader) , 
and  the  different  choices  within  the  language  are  well 
delineated.  The  author’s  conclusion  is  the  main  source  for  the 
following  quotations: 

It  is  probably  the  most  disheartening  experience  for  a  language 
designer  to  discover  how  features  provided  with  honest  intentions 
are  "ingeniously"  misused  to  betray  the  language’s  very 
principles. ... 

Instead  of  relying  too  much  on  either  antiquated  "debugging 
tools"  or  on  futuristic  automatic  program  verifiers,  we  should 
give  more  emphasis  to  the  systematic  construction  of  programs 
with  languages  that  facilitate  transparent  formulation  and 
automatic  consistency  checks.... 

The  urge  to  gain  flexibility  and  "power"  through  generalizations 
must  be  restrained.  A  generalization  may  easily  be  carried  too 
far  and  have  revolutionary  consequences  on  implementation.... 

In  many  cases,  security  and  flexibility  are  antagonistic 
properties. . . . 

A  rich  language  may  be  welcome  to  the  professional  program  writer 
who  principal  delight  is  his  familiarization  with  all  its 
intricate  facets.  But  the  interests  of  the  program  reader 
dictate  a  reasonably  frugal  language.  People  who  want  to 
understand  a  program  (including  their  own),  compilers,  and 
automatic  verification  aids  all  belong  to  the  class  of  readers. 
In  the  interest  of  increased  quality  to  software  products,  we  may 
be  well  advised  to  get  rid  of  many  facilities  of  modern,  baroque 
programming  languages  that  are  widely  advertised  in  the  name  of 
"user-orientation,"  "scientific  sophistication,"  and  "progress." 
[CR29,417  O.L.  Lecarme] 


From  the  Text 
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■■■  Wirth,  N. ;  Comment  on  a  Note  on  Dynamic  Arrays  in  PASCAL; 
SIGPLAN  Notices  11,1  (January  1976)  pp. 37-38. 


■■■  Woodger,  M.;  On  Semantic  Levels  in  Programming;  IFIP  1971, 
Nort h-Holland  (1972)  pp. 402-407. 

The  first  paragraph  sums  things  up  quite  neatly: 

This  paper  is  about  an  attitude  to  programming,  the  consequences 
of  this  approach  for  the  design,  description,  testing,  and 
modification  of  programs,  its  bearing  upon  the  use  of  general- 
purpose  programming  languages,  and  the  light  which  it  throws  upon 
desirable  features  of  programming  languages. 

The  author's  "attitude"  is  to  stratify  the  solution  of  a  problem 
into  a  number  of  levels,  each  described  in  terms  of  primitive 
operations  that  are  themselves  described  on  lower  levels.  The 
description  of  each  level  is  independent  of  the  descriptions  of 
any  other  levels. 

Such  a  hierarchy  is  the  key  to  program  portability,  and  certainly 
aids  in  the  conceptualization  of  solutions.  Its  only  drawback  is 
a  tendency  toward  inefficiency.  The  paper  is  not  a  critical 
analysis  of  the  level  concept;  the  author  contents  himself  with  a 
description  of  its  meaning  and  an  enumeration  of  its  strengths. 
What  is  said  is  said  well,  but  I  would  have  preferred  a  closer 
scrutiny  of  both  good  and  bad  points.  [CR24,757  W.M.  Waite] 
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